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SUBJECT:  Evaluation  of  the  Reserve  Component  Automation  System 
(Report  No.  97-019) 


We  are  providing  this  report  for  your  review  and  comment.  We  conducted  the 
evaluation  in  response  to  a  request  from  the  Assistant  Secretary  of  Defense  for  Reserve 
Affairs,  acting  upon  congressional  direction.  We  considered  management  comments  on 
a  draft  of  this  report  in  preparing  the  final  report. 

DoD  Directive  7650.3  requires  that  all  recommendations  be  resolved  promptly. 
Therefore,  we  request  comments  from  the  Assistant  Secretary  of  Defense  (Command, 
Control,  Communications,  and  Intelligence)  on  Recommendation  A. 2.,  and  the  Chief, 
National  Guard  Bureau  on  Recommendation  A.l.a.(2).  by  January  10,  1997. 

We  appreciate  the  courtesies  extended  to  the  evaluation  staff.  Questions  on  the 
evaluation  should  be  directed  to  Mr.  Kenneth  H.  Stavenjord,  Technical  Director,  at 
(703)  604-8952  (DSN  664-8952),  or  Mr.  Gregory  R.  Donnellon,  Project  Manager,  at 
(703)  604-8946  (DSN  664-8946).  If  management  requests,  we  will  provide  a  formal 
briefing  on  the  evaluation  results.  See  Appendix  F  for  the  report  distribution.  The 
evaluation  team  members  are  listed  inside  the  back  cover. 


Robert  J.  Lieberman 
Assistant  Inspector  General 
for  Auditing 
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Report  No.  97-019  November  1,  1996 

(Project  No.  6PT-5013) 

Evaluation  of  the  Reserve  Component  Automation  System 

Executive  Summary 


Introduction.  The  Assistant  Secretary  of  Defense  for  Reserve  Affairs,  acting  upon 
congressional  direction,  requested  a  technical  assessment  of  the  Reserve  Component 
Automation  System  (RCAS).  The  RCAS  contains  a  combination  of  commercial  off- 
the-shelf,  Government  off-the-shelf,  and  developed  hardware,  software,  and 
telecommunications  components.  We  reviewed  the  RCAS  requirements,  architecture, 
telecommunications,  software  development,  cost,  schedule,  funding,  and  fielding  plan. 

Objective.  Our  objective  was  to  determine  whether  the  RCAS  was  adequately  funded, 
was  executable,  would  meet  the  Army's  National  Guard  and  Reserve  requirements,  and 
would  be  fielded  to  all  operational  units  according  to  an  approved  plan. 

Technical  Assessment  Results.  The  RCAS  commercial  off-the-shelf  infrastructure 
(personal  computers,  office  automation  software,  and  telecommunications)  alone, 
without  the  developed  software,  will  meet  many  Reserve  Component  operational 
requirements.  When  complete,  the  RCAS  infrastructure  and  developed  software  should 
provide  the  U.S.  Army  and  its  Reserve  Component  decisionmakers  the  capability  to 
effectively  manage  the  information  resources  supporting  readiness  and  mobilization 
preparedness.  However,  significant  risks  to  successful  RCAS  Program  execution 
concern  data  and  application  software  development,  telecommunication  requirements 
and  funding,  and  commercial  off-the-shelf  budget  risks. 

The  RCAS  Program  Management  Office  underestimated  costs  and  planned  insufficient 
funding  for  the  data  and  applications  software  development  by  approximately  $160 
million.  Because  of  the  insufficient  funding,  developing  software  in  the  required 
language  will  cause  schedule  slips  and  the  Army  National  Guard  and  the  Army  Reserve 
requirements  not  being  fully  met  (Finding  A). 

The  Chief,  National  Guard  Bureau,  neither  identified  specific  telecommunications 
requirements  for  equipment  and  services  nor  determined  total  communications  cost  for 
the  RCAS  program.  As  a  result,  the  RCAS  Program  Management  Office  has  not 
completed  a  documented,  validated,  and  comprehensive  telecommunications 
management  plan  to  obtain  the  most  cost-effective  telecommunications  circuit 
configuration  and  is  unable  to  determine  the  total  cost  of  the  telecommunications 
portion  of  the  RCAS  program  (Finding  B). 

Budgeted  funds  to  purchase  the  RCAS  commercial  off-the-shelf  infrastructure  (personal 
computers,  office  automation  software,  and  telecommunications)  are  at  risk  from  other 
areas  of  the  program  that  are  underbudgeted.  Insufficient  infrastructure  investment 
could  force  the  Army  National  Guard  and  Army  Reserve  units  to  wait  more  than 
6  years  for  the  anticipated  benefits  from  deploying  the  RCAS  commercial  off-the-shelf 
infrastructure  (Finding  C). 


Summary  of  Recommendations.  We  recommend  that  the  Chief,  National  Guard 
Bureau,  cease  further  data  and  applications  development  effort  until  selection  of  Ada 
(or  other  approved  computer  language)  and  reestimate  the  cost  and  schedule  of  the 
project.  We  also  recommend  requiring  full  justification  if  an  Ada  waiver  is  proposed 
and  cease  the  more  than  $2  million  procurement  of  the  structured  query  language  server 
and  the  selected  fourth-generation  language  products  planned  for  FY  1997  unless  an 
Ada  waiver  is  granted  and  pilot  applications  are  completed  successfully. 

Before  procuring  additional  RCAS  telecommunication  equipment  and  services,  we 
recommend  that  the  Chief,  National  Guard  Bureau,  ensure  that  a  baseline  is 
established,  telecommunications  requirements  are  validated,  the  number  of  subscribers 
are  identified,  future  users  telecommunications  requirements  are  validated,  a 
configuration  management  plan  is  completed,  the  total  cost  is  determined,  budgetary 
costs  are  projected,  and  a  funding  program  for  the  Army  Reserve  and  National  Guard 
is  established. 

We  further  recommend  that  the  Chief,  National  Guard  Bureau,  formally  baseline  the 
commercial  off-the-shelf  infrastructure  delivery  schedule  and  quantities,  and  review  the 
use  of  computer  systems  provided  by  other  sources. 

Management  Comments.  The  National  Guard  concurred  with  our  recommendation  to 
baseline  the  commercial  off-the-shelf  hardware  and  software  deliveries.  However,  the 
National  Guard  nonconcurred  with  the  recommendations  to  cease  development  in  the 
planned  language  or  to  seek  a  waiver  from  the  Ada  requirement.  The  Army  rationale 
was  that  the  fourth  generation  language  was  a  COTS  advanced  software  technology,  so 
no  waiver  from  Ada  was  needed.  The  Assistant  Secretary  of  Defense  (Command, 
Control,  Communications,  and  Intelligence)  (ASD[C3I])  agreed  with  the  Army 
interpretation  of  the  language  policy.  The  National  Guard  Bureau  nonconcurred  with 
recommendations  to  baseline  and  validate  the  telecommunications  requirements, 
because  telecommunications  plans  were  subsequently  updated  with  the  required  data. 
The  ASD(C3I)  partially  concurred  with  the  recommendations  to  baseline  the 
telecommunications  plan,  acknowledging  that  required  details  were  missing.  However, 
ASD(C3I)  nonconcurred  with  the  recommendation  to  perform  site  surveys,  since  RCAS 
will  utilize  excess  capacity  on  other  networks  whenever  possible.  See  Part  I  for  a 
summary  of  management  comments  and  Part  III  for  the  complete  text  of  management 
comments. 

Evaluation  Response.  The  computer  language  regulation  issues  were  satisfied  by  die 
RCAS  Program  Management  Office  prompt  action  in  obtaining  the  ASD(C3I) 
interpretation  of  the  policy,  resulting  in  a  determination  of  compliance.  However, 
designation  of  a  fourth  generation  language  as  an  advanced  software  technology  avoids 
consideration  of  embedded  programming  language  usage  risks  and  life-cycle  cost 
impact.  The  risks  are  particularly  prevalent  in  areas  of  maintainability,  portability, 
reliability,  reusability,  and  clarity  of  source  code.  Also,  the  National  Guard  was 
non-responsive  to  the  $12.1  million  funding  shortfall  we  calculated  for  software 
maintenance,  claiming  instead  that  it  had  planned  for  maintenance  and  software  growth 
in  future  years.  We  are  indicating  a  planning  calculation  error,  not  a  methodology 
difference.  We  continue  to  recommend  that  software  maintenance  costs  be 
recalculated. 

In  light  of  the  approval  action  by  ASD(C3I),  we  withdrew  Recommendation  A.l.a.(l). 
to  cease  development  until  Ada  is  selected.  Instead,  we  directed  recommendations  to 
the  ASD(C3I)  to  monitor  and  periodically  assess  the  RCAS  software  development  risk 
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management  with  a  view  to  identifying  and  correcting  variances  in  a  timely  manner. 
Concerning  Recommendation  A.l.a.(2).,  an  additional  response  is  required.  We 
request  the  additional  comments  by  January  10,  1997. 

Quick  action  by  the  RCAS  Program  Management  Office  in  submitting  cost  and  risk 
management  data  to  the  ASD(C?I)  and  obtaining  his  endorsement  of  the  program's 
approach  met  the  intention  of  our  telecommunications  recommendation  to  baseline  the 
system  and  validate  the  system's  requirements.  The  Army  actions  in  baselining  the 
Acquisition  Program  for  the  delivery  schedules  and  in  deciding  to  utilize  open 
architecture  and  existing  National  Guard  and  Army  computer  resources  is  responsive  to 
our  recommendations. 

Concerns  about  telecommunications  requirements  were  satisfied  by  the  ASD(C3I) 
requiring  the  Program  Management  Office  to  have  a  validated  telecommunications 
plan,  including  missing  requirements,  for  Major  Automated  Information  System 
Review  Council  approval. 
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Evaluation  Results 


Evaluation  Background 


The  Reserve  Component  Automation  System  (RCAS)  acquisition  program  is 
managed  by  the  Chief,  National  Guard  Bureau.  The  RCAS  is  an  automated 
information  management  system  that  will  assist  soldiers  in  the  Reserve 
Component  with  their  day-to-day  office  administration  and  mobilization 
planning  and  execution  applications.  The  Army  Reserve  Component  consists  of 
the  Army  National  Guard  and  Army  Reserve  units.  The  RCAS  consists  of 
commercial  off-the-shelf  (COTS)  telecommunications,  computer  equipment,  and 
software,  including  the  retrofit  of  currently  fielded  equipment;  limited  system 
sustainment;  application  software  through  the  use  of  Government  off-the-shelf 
(GOTS)  software;  and  the  development  of  new  applications  that  satisfy  the 
functional  requirements  for  maintaining  data,  automating  business  processes, 
and  interfacing  with  external  systems. 

In  1988,  Congress  directed  that  the  Army  procure  the  RCAS,  using  Office  of 
Management  and  Budget  Circular  A-109,  "Major  Systems  Acquisitions,"  April 
1976.  In  1991,  the  RCAS  contract  was  awarded  to  Boeing  Information 
Systems,  Inc.  Originally,  the  RCAS  Program  Management  Office  (PMO) 
planned  to  field  hardware  by  1994  and  software  by  1996.  Time  delays  and  an 
unfinanced  requirement  of  more  than  $200  million  resulted  in  a  Secretary  of  the 
Army  directive  to  examine  the  RCAS  program.  In  February  1995,  the  Chief, 
National  Guard  Bureau,  requested  that  a  team  of  experts  (the  Red  Team) 
consisting  of  the  Active  Army,  Army  National  Guard,  and  Army  Reserve  be 
formed  to  review  the  program.  The  Red  Team  recommended  changing  to  a 
personal  computer  COTS/GOTS-based  architecture,  removing  multilevel 
security  requirements,  utilizing  rapid  prototyping  of  functional  applications 
software,  centralizing  data  at  State  Area  Commands  and  Regional  Support 
Commands,  and  establishing  a  Customer  Focus  Team. 

In  April  1995,  a  working  group  called  the  Validation  Assessment  Team  was 
assembled  to  validate  the  Red  Team's  recommendations  and  develop  a  program¬ 
wide  plan  for  implementation.  The  Validation  Assessment  Team  objectives  and 
schedule  included  determining  cost  implications  of  the  Red  Team 
recommendations,  finalizing  RCAS  architecture  and  plans  for  implementation, 
and  restructuring  the  RCAS  contract  to  accommodate  the  revised  solution.  The 
Active  Army,  the  National  Guard,  the  Army  Reserve,  the  Office  of  the 
Secretary  of  Defense,  and  the  Congress  reviewed  the  revised  RCAS  program 
and  agreed  with  the  new  RCAS  program  structure. 

The  restructured  RCAS  contract  was  implemented  February  1,  1996,  with 
Boeing  Information  Services,  Inc.  The  contractor  is  required  to  provide  COTS 
telecommunications,  computer  equipment,  and  software,  including  the  retrofit 
of  currently  fielded  equipment;  limited  system  sustainment;  application  software 
through  the  use  of  GOTS/COTS-based  development  and  the  development  of 
new  applications;  and  the  program  management,  system  engineering,  and  data 
modeling  support  required  to  integrate  and  prioritize  the  above  activities  within 
the  current,  design-to-cost  and  funding  limitations.  The  period  of  performance 
for  the  restructured  RCAS  contract  is  February  1,  1996,  through  September  30, 
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2002,  and  is  subject  to  annual  renewal  options.  The  total  value  of  the  signed 
RCAS  contract  is  $760.9  million;  the  contract  provides  for  connecting  more 
than  56,100  workstations  for  supporting  mobilization  of  the  Army  National 
Guard  and  Reserve  units  and  performing  office  automation  functions. 

The  Report  of  the  House  Appropriations  Committee  for  FY  1996  directed  the 
Assistant  Secretary  of  Defense  for  Reserve  Affairs  to  certify  that  the 
Department  of  Defense  has  a  fully  funded  RCAS  program  that  is  executable, 
meets  the  requirements  of  the  Army  National  Guard  and  the  Army  Reserve,  and 
can  eventually  field  the  equipment  to  all  operational  units  with  valid 
requirements  for  the  RCAS.  The  House  Appropriations  Committee  directed 
that  no  more  than  half  of  the  FY  1996  RCAS  procurement  funds  be  obligated 
before  the  certification.  The  Committee  also  directed  that  the  Assistant 
Secretary  of  Defense  arrange  for  an  independent  technical  assessment  by  an 
organization  that  is  independent  of  the  Army.  The  Assistant  Secretary  of 
Defense  requested  the  Inspector  General,  DoD,  to  conduct  the  technical 
assessment. 


Evaluation  Objective 


The  objective  of  our  evaluation  was  to  determine  whether  the  RCAS  program 
has  been  fully  funded,  is  executable,  will  meet  the  requirements  of  the  Army 
National  Guard  and  die  Army  Reserve,  and  has  a  plan  prepared  to  ensure 
fielding  of  the  equipment  to  all  operational  units.  See  Appendix  A  for  a 
discussion  of  the  evaluation  scope  and  methodology.  Appendix  B  discusses 
prior  audit  coverage  and  other  reviews.  Appendix  C  discusses  technical  support 
available  to  the  PMO.  Also,  see  Appendix  E  for  a  list  of  organizations  visited 
or  contacted  during  the  evaluation. 
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Finding  A.  Data  and  Application 
Software  Development 

The  RCAS  Program  Management  Office  underestimated  costs  and 
planned  insufficient  funding  for  the  data  and  applications  software 
development  by  about  $160  million.  The  PMO  did  not  obtain  a  waiver 
to  the  Ada  requirement,  significantly  overestimated  the  software 
development  productivity,  and  underestimated  the  maintenance  portion. 
As  a  result  of  the  insufficient  funding,  the  software  development  in  the 
required  language  will  cause  schedule  slips  and  the  Army  National 
Guard  and  the  Army  Reserve  requirements  will  not  be  fully  met. 


Software  Development  Approach 


RCAS  is  an  integrated  computing  system  developed  primarily  to  enhance  the 
readiness  of  the  Reserve  Component  of  the  Army.  The  RCAS  consists  of  a 
delivery  system  portion  and  a  data  and  applications  portion.  The  delivery 
system  includes  COTS  hardware,  software,  and  telecommunications  that  provide 
office  automation  and  electronic  mail.  The  data  and  application  software  to 
satisfy  the  functional  requirements  for  maintaining  data,  automating  business 
processes,  and  interfacing  with  external  systems  is  a  development  effort. 

The  data  and  application  software  development  will  satisfy  approximately  three- 
fourths  of  the  functional  requirements  with  new  applications  and  the  remainder 
by  integrating  GOTS  software.  The  PMO  will  use  the  evolutionary  strategy  to 
develop  the  new  applications.  This  strategy  develops  a  system  in  builds  and 
acknowledges  that  the  user  needs  and  system  requirements  are  only  partially 
defined  up  front  and  then  are  refined  in  each  succeeding  build.  A  build  is  a 
version  of  software  that  meets  a  specified  subset  of  the  requirements  that  the 
completed  software  will  meet. 

The  evolutionary  strategy  used  by  RCAS  is  a  Rapid  Application  Fielding 
Methodology  based  on  a  widely  accepted  industry  practice  known  as  rapid 
application  development.  Rapid  Application  Fielding  Methodology  is 
characterized  by  the  following: 

o  Extensive  and  on-going  user  involvement  in  the  requirements  and 
preliminary  design  phases. 

o  Development  of  applications  in  small  increments  (known  as 
"timeboxes")  under  tightly  controlled  deadlines. 

o  Small  development  teams  with  developers,  database  analysts,  test 
analysts,  and  users  represented.  Significant  decisionmaking  is  delegated  to  the 
teams.  Users  on  each  team  speak  for  all  users  of  the  timebox  application. 
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o  Extensive  use  of  prototyping. 

o  Exploitation  of  opportunities  for  software  reuse  (including  GOTS  and 
COTS)  and  for  use  of  modem  software  development  tools. 

o  Information  engineering  techniques,  such  as  data  and  process 
modeling. 

The  RCAS  Validation  Assessment  Team  and  contractor  used  the  function  point 
analysis  approach  to  size  the  software.  Function  points  (FP)  are  the  weighted 
sums  of  five  factors  (inputs,  outputs,  inquiries,  files,  and  interfaces)  that  relate 
to  user  requirements.  These  counts  are  then  multiplied  by  established  values  to 
adjust  for  the  software's  complexity.  Based  on  prior  experience,  the  final 
function  point  figure  can  be  converted  into  a  reasonably  good  estimate  of 
required  development  resources. 

The  funding  allocated  to  the  Data  and  Applications  software  development  time 
and  materials  portion  of  the  contract  was  not  sufficient  for  an  Ada  development 
approach.  Therefore,  the  Validation  Assessment  Team  selected  a  fourth- 
generation  language  approach  based  on  its  efficiency. 


Development  Language  Issues 


DoD  policy  is  to  use  COTS  software  whenever  it  meets  DoD  requirements. 
However,  when  the  DoD  must  develop  unique  software  to  meet  its  needs,  DoD 
Directive  3405.1,  "Computer  Programming  Language  Policy,"  April  2,  1987, 
requires  that  software  be  written  in  the  Ada  programming  language.  Further, 
the  Ada  programming  language  is  the  single,  common,  high-order  computer 
programming  language  for  all  computer  resources  used  in  the  Army.  Ada  is 
presumed  cost-effective  over  the  life-cycle  of  the  application  by  Army  policy  for 
all  new  development  or  modification  of  more  than  one-third  of  a  DoD 
application  regardless  of  size  or  cost.  In  such  cases,  Ada  must  be  used  unless  a 
waiver  is  granted. 

The  Validation  Assessment  Team  determined  that  the  productivity  levels 
associated  with  Ada  coding  were  3.5  to  4  function  points  per  man-month. 
Current  RCAS  budget  allocations  cannot  support  the  costs  of  this  productivity 
level;  therefore,  a  new  approach  was  proposed  minimizing  the  amount  of  Ada 
code  that  must  be  written.  The  Validation  Assessment  Team  approach  was  to 
meet  RCAS  mission  functionality  primarily  through  the  use  of  commercially 
available  software  and  fourth-generation  languages  (4GLs)  rather  than  custom- 
developed  software  in  a  high-order  language  such  as  Ada. 
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The  RCAS  Validation  Assessment  Team  Final  Report,  July  24,  1995,  stated: 

[the  new  software  development]  approach  is  a  COTS-based  approach 
and  is  consistent  with  direction  contained  in  DoD  Directive  3405.1, 

Computer  Programming  Language  Policy  that  identifies  the  following 
priority  preference  based  on  an  analysis  of  the  life-cycle  costs  and 
impact: 

a.  Off-the-shelf  application  packages  and  advanced'  software 
technology. 

b.  Ada-based  software  and  tools. 

c.  Approved  standard  high  order  languages. 

Fourth-generation  languages  generate  code  for  an  application.  The  existing 
policies;  DoD  Directive  3405.1,  DoD  Regulation  5000. 2-R,  "Mandatory 
Procedures  for  Major  Defense  Acquisition  Programs  and  Major  Automated 
Information  System  Acquisition  Programs,"  March  15,  1996,  and  Headquarters, 
Department  of  the  Army  Letter  25-95-1,  "Change  to  Headquarters,  Department 
of  the  Army  Letter  25-94-1,  Implementation  of  the  Ada  Programming 
Language,"  July  17,  1995,  do  not  adequately  address  code  generators.  The 
policies  do  state  that  a  waiver  is  not  required  to  use  COTS  applications  and 
advanced  software  technology  that  is  not  modified  or  maintained  by  the 
Department  of  Defense.  The  RCAS  PMO  and  the  Army  Director  of 
Information  Systems  for  Command,  Control,  Communications,  and  Computers 
have  interpreted  this  guidance  to  include  COTS  4GL  code  generators. 

However,  the  RCAS  use  of  a  COTS  code  generator  will  require  coding  and 
maintenance  at  the  generated  code  level.  Because  the  PMO  will  develop  and 
maintain  software  at  the  generated  code  level,  DoD  policy  requires  an  Ada 
waiver.  This  position  on  die  requirement  for  an  Ada  waiver  is  consistent  with 
the  interpretation  provided  to  the  Army  by  a  ASD(C3I)  memorandum  that 
states:  "The  Army  needs  to  ensure  that  the  code  generator  will  do  everything 
that  needs  to  be  done  now  and  in  the  future.  If  at  any  time  the  actual  code  has 
to  be  modified  (even  slightly)  and  it  is  not  Ada,  the  Army  will  be  in  violation  of 
the  policy." 

The  selected  4GL  is  predicated  on  the  idea  that  the  developer  would  modify  the 
generated  code  to  customize  the  user  interface,  processing,  and  application 
interfaces.  The  selected  4GL  includes  tools  to  facilitate  such  code  level 
changes.  The  following  are  examples  that  require  coding  at  the  generated  code 
level. 


o  disabling  a  keystroke  in  a  data  window; 
o  implementing  cut,  copy,  and  paste  in  the  "Edit"  menu; 
o  scrolling  row  by  row  instead  of  scrolling  by  page  or  by  group; 
o  using  shift-Fl  for  help; 


6 


Finding  A.  Data  and  Application  Software  Development 


o  determining  the  last  item  clicked  on  a  multi-select  listbox; 

o  passing  Windows  messages  into  an  application; 

o  providing  text  search  in  a  drop  down  data  window; 

o  conditionally  preventing  user  input  into  columns; 

o  updating  multiple  database  tables  from  the  same  data  window; 

o  reading  a  file  larger  than  32,766  bytes; 

o  sending  data  from  an  application  via  e-mail;  and 

o  determining  whether  a  Windows  application  is  running  in  Windows 
NT. 

These  and  other  routine  requirements  are  highly  likely  in  the  RCAS  applications 
and  would  require  coding  at  the  generated  code  level.  Even  if  Ada  was  used 
whenever  changes  were  needed  to  the  selected  4GL  applications,  generated  or 
C  code  changes  would  be  necessary  to  transfer  control  and  data  between  the 
languages.  Therefore,  without  a  waiver,  the  regulations  require  RCAS  to  use 
Ada. 

If  the  PMO  pursues  an  Ada  waiver,  the  justification  should  include  how  the 
PMO  will  abate  the  additional  risks  of  4GL  development.  These  4GL 
development  risks  include  the  following. 

o  The  RCAS  applications  may  be  too  large  for  the  code  generator. 
Fourth-generation  languages  have  been  used  extensively  for  prototyping  and  ad 
hoc  application  development.  The  large  RCAS  applications  may  cause 
overflows  of  internal  tables  and  memory  exceptions  in  the  code  generator. 

o  The  applications  will  run  too  slowly  and  take  too  much  memory. 
Fourth-generation  languages  automatically  include  application  domain  services 
that  may  or  may  not  be  used  by  the  application.  The  RCAS  contract  specifies 
an  interpretive  4GL.  There  is  considerable  risk  that  RCAS  users  will  not  accept 
the  application  start-up  delays  and  response  times.  There  is  some  risk  that  the 
applications  will  use  too  much  disk  space  and  that  useful  sets  of  applications 
cannot  be  loaded  at  the  same  time. 

o  Windows  NT  and  code  generator  changes  may  cause  additional 
application  changes.  Frequent  changes  in  Windows  NT  and  the  code  generator 
can  be  expected  until  the  market  place  matures.  These  changes  may  cause 
additional  application  updates,  testing,  and  redelivering.  Application  changes 
would  cause  support  cost  increases,  delivery  and  reinstallation  costs,  and 
possible  configuration  variety  in  the  field. 

o  Development  and  support  tools  for  the  code  generator  are  inadequate. 
Production  sizing,  productivity,  complexity  measurement,  execution  tracing, 
and  test  case  capture/replay  tools  may  not  be  available.  The  code  responsible 
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for  execution  problems  may  not  be  identified.  The  development  at  the  code 
generator  and  generated  code  levels  means  that  the  testing  and  support  must  also 
be  at  multiple  levels.  The  lower  level  changes  may  be  forgotten  or  not  changed 
to  match  die  higher  level  changes.  Test  tools  may  not  be  available  to  test 
generated  code  changes. 

o  The  RCAS  applications  may  become  unsupportable.  The  selected 
code  generator  uses  a  proprietary  nonstandard  language  with  no  alternative 
source  or  translators.  Currently  about  two  dozen  4GL  products  are  competing 
for  top  places  in  productivity,  power,  graphical  user  interface,  and  rapid 
application  development  project  support.  The  selected  4GL  may  become 
obsolete  or  other  4GLs  may  dominate.  The  developed  applications  may  become 
unsupportable  and  may  need  to  be  replaced. 

In  addition  to  these  regulatory  and  risk  issues,  the  RCAS  PMO  has  not 
demonstrated  that  the  selected  4GL  has  the  flexibility  and  performance  needed 
for  RCAS  by  successfully  completing  the  pilot  applications.  In  fact,  the  RCAS 
PMO  has  not  demonstrated  that  the  selected  4GL  provides  all  functions  needed 
to  develop  a  representative  application.  However,  the  PMO  is  buying  the 
Structured  Query  Language  server  and  the  selected  4GL  products  with  a 
contract  sub-Contract  Line  Item  Number  for  $2.2  million  in  FY  1996.  No 
funds  were  budgeted  for  additional  software  licenses  or  updates  that  may  be 
required  within  the  7  year  planned  software  development. 


Development  Language  Cost  Impact 


The  Validation  Assessment  Team  decomposed  RCAS  functionality  into  136 
timeboxes  to  be  used  for  development  and  GOTS  integration.  The  nominal 
timebox  was  500  function  points  to  be  developed  over  28  weeks,  including 
6  weeks  of  formal  tests,  by  4  contractor  employees  per  timebox,  which  equates 
to  18  function  points  per  man-month  (FP/MM).  The  Validation  Assessment 
Team  then  reduced  the  productivity  to  account  for  the  DoD  environment  and 
learning  curve  with  the  new  tool  suite.  The  resultant  productivity  used  for 
project  planning  and  costing  was  from  10  to  18  FP/MM  over  the  development 
period.  The  contractor,  in  its  latest  Contract  Change  Proposal,  decomposed  the 
RCAS  functionality  into  145  total  timeboxes,  129  to  be  used  for  development 
and  GOTS  integration  and  16  for  maintenance.  The  contractor's  productivity 
estimates  were  even  higher,  steadily  increasing  from  14  to  20  FP/MM  over  the 
development  cycle.  The  Validation  Assessment  Team  and  contractor  estimated 
productivity  planning  on  4GL  development. 

The  contractor's  proposal  did  not  include  any  productivity  factors  associated 
with  the  use  of  third-generation  languages,  like  Ada.  Without  a  waiver,  DoD 
and  Army  policies  require  RCAS  to  use  Ada,  and  our  development  productivity 
and  cost  estimates  are  so  based.  Data  collected  from  a  large  number  of  software 
development  projects  and  used  by  the  Validation  Assessment  Team  indicates  the 
overall  software  productivity  rates  in  the  United  States  average  about 
five  FP/MM  and  about  eight  FP/MM  for  Management  Information  Systems. 
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Military  systems,  however,  average  about  three  FP/MM  due  to  more  stringent 
development  requirements.  This  average  is  consistent  with  the  results  of  the 
Validation  Assessment  Team's  modeling  analysis  showing  a  productivity  rate  of 
about  three  to  five  FP/MM  based  on  RCAS  historical  development  data.  Larger 
systems  tend  to  have  more  requirements  growth  during  development,  longer 
schedule  delays,  higher  maintenance  costs,  and  greater  risk  of  failure  than 
smaller  development  efforts.  With  approximately  60,000  function  points, 
RCAS  would  be  classified  as  one  of  the  largest  systems  and,  therefore,  would 
have  among  the  lowest  productivity  rates.  In  addition,  a  comparison  of 
development  languages  indicates  Ada  has  the  lowest  productivity  rate  of  most 
comparable  languages  such  as  Basic,  C,  FORTRAN,  COBOL,  Pascal,  and  PL/1 
and  is  much  lower  than  newer  languages  such  as  C  +  +  ,  Visual  Basic, 
SMALLTALK,  and  4GLs. 

In  summary,  the  development  productivity  used  in  program  planning  was  14  to 
20  FP/MM.  But  Ada  or  other  approved  high-order  language  is  required  and  has 
a  realistic  development  productivity  of  three  to  five  FP/MM.  Therefore,  the 
planned  productivity  is  five  times  the  realistic  productivity  using  an  approved 
language.  As  a  result,  the  time  and  materials  funding  planned  is  underestimated 
by  $150  million.  Our  $150  million  estimate  is  consistent  with  the  Validation 
Assessment  Team's  cost  model.  The  Validation  Assessment  Team  reported  that 
if  4GLs  were  excluded  and  all  code  was  developed  in  Ada,  a  net  increased  cost 
for  software  and  data  would  be  $168.7  million. 


Other  Productivity  Risks 


The  RCAS  PMO  and  contractor  did  not  consider  other  productivity  adjustments 
in  the  above  calculations  for  either  Ada  or  the  selected  4GL.  Development 
productivity  reductions  for  the  very  large  project,  the  impact  of  the  new 
development  process  Rapid  Application  Fielding  Methodology,  and  the 
development  contractor's  Capability  Maturity  Model  level  were  not  considered. 

The  Carnegie  Mellon  University  Software  Engineering  Institute  Capability 
Maturity  Model  provides  a  benchmark  of  widely  proven  principles  for  quality, 
which  is  recognized  by  both  engineering  and  manufacturing  and  has  been 
demonstrated  to  be  effective  for  software.  The  purpose  of  the  model  is  to  help 
organizations  determine  their  current  capabilities  and  identify  their  most  critical 
issues.  The  model  characterizes  the  level  of  an  organization's  maturity  based  on 
the  extent  to  which  measurable  and  repeatable  software  engineering  and 
management  processes  are  institutionalized.  The  Capability  Maturity  Model 
levels  range  from  a  low  of  one  to  a  high  of  five. 

The  RCAS  contract  stipulates  that,  before  the  Government  awards  any  Data  and 
Application  Task  Orders  beyond  the  first  planned  set,  the  contractor  is  required 
to  achieve  Software  Engineering  Institute  Level  2  certification  in  software 
development  procedures.  The  contractor  will  use  the  Software  Engineering 
Institute  Capability  Maturity  Model  Plan  approach  to  achieve  Software 
Engineering  Institute  Level  2. 
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Capability  Maturity  Model  Level  1,  the  initial  level,  characterizes  the 
organization  as  having  ad  hoc  or  chaotic  processes,  such  as: 

o  no  formal  procedures,  cost  estimates,  or  project  plans; 

o  no  management  mechanism  to  ensure  procedures  are  followed; 

o  tools  not  well  integrated; 

o  change  control  is  lax;  and 

o  senior  management  does  not  understand  key  issues. 

Level  1  organizations  suffer  from  chronic  scheduling  problems.  When 
organizations  plan  inadequately  and  overcommit  themselves,  they  have  little 
time  to  perform  even  the  basic  tasks  of  development  and  testing.  Product 
defects  become  numerous,  rework  increases,  and  detailed  procedures  are 
ignored.  The  intent  of  adopting  the  practices  of  Software  Engineering  Institute 
Level  2  is  to  provide  a  solid  management  foundation  for  software  development. 
This  foundation  for  software  development  results  in  a  stable  environment  that 
enables  further  improvements.  Process  stability  comes  from  the  increase  in 
accuracy  and  predictability  of  schedules,  early  identification  and  attention  to 
problems,  the  management  of  commitments,  and  the  control  of  changes  to  the 
product. 

Capability  Maturity  Model  Level  2,  the  repeatable  level,  characterizes  the 
organization  as  being  intuitive  with  the  following  characteristics: 

o  process  dependent  on  individuals; 

o  basic  project  controls  established; 

o  strength  in  doing  similar  work,  but  new  challenges  present  major  risk; 
and 


o  orderly  framework  for  improvement  lacking. 

The  three  higher  Capability  Maturity  Model  levels  are  defined,  managed,  and 
optimized.  While  achievement  of  Capability  Maturity  Model  Level  2  improves 
the  management  foundation  of  the  software  organization,  the  production  amount 
and  quality  is  still  inconsistent  from  team  to  team  and  product  to  product.  With 
RCAS  system  development,  this  inconsistency  combined  with  the  organization's 
growth  does  not  support  the  planned,  steadily  increased  productivity  from  14  to 
20  FP/MM. 
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Underestimated  Software  Maintenance 


The  contractor's  data  and  applications  development  size  estimates  for  the 
restructured  program  are: 

39,590  FP  -  New  application  development 

11,825  FP  -  Provided  by  GOTS  software 

2,960  FP  -  Integration  of  GOTS  software 

6,125  FP  -  Maintenance 


60,500  FP  -  Total 

This  total  estimate  is  equivalent  to  4,300,000  source  lines  of  Ada  code.  RCAS 
is  a  very  large  software-intensive  program. 

The  contractor's  maintenance  estimate  was  based  on  a  15  to  16  percent  annual 
change  traffic.  The  15-percent  annual  change  traffic  is  based  on  historical  data 
and  assumes  a  7-year  life-cycle  for  software  (7  years  times  15  percent  =  105 
percent). 

Our  conservative  calculation,  based  on  the  15  percent  annual  change  and  the 
above  size  estimates,  yields  a  range  of  17,900  to  36,000  FPs.  Fault  repairs  on 
fielded  software  are  not  included,  but  they  must  be  estimated  and  added  to  get 
the  total  maintenance  estimate.  By  selecting  18,125  FP,  a  conservative  total 
maintenance  estimate,  we  calculated  that  the  software  maintenance  was 
underestimated  by  12,000  FP  (852,000  source  lines  of  code). 

Using  the  PMO  estimate  of  $61.2  million  for  the  total  60,500  FP,  we 
determined  the  additional  12,000  FP  will  cost  an  additional  $12.1  million. 

In  addition,  the  RCAS  contractor  has  planned  the  maintenance  timeboxes  at  the 
same  productivity  as  the  development.  However,  the  software  maintenance 
phase  has  historically  had  dramatic  decreases  in  productivity.  Productivity 
drops  of  40:1  have  been  reported.  The  variety  and  undefined  scope  of  the 
changes  make  software  maintenance  costs  difficult  to  estimate.  Software 
maintenance  also  includes  considerable  wheel-spinning  activities,  and  the 
complexity  of  the  software  increases  the  longer  the  software  is  in  the  support 
phase.  A  maintenance  productivity  lower  than  the  development  productivity 
would  provide  more  realistic  project  plans. 
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Summary 


The  data  and  application  portion  of  RCAS  is  a  large  software  application 
development  effort.  The  RCAS  PMO  selected  a  4GL  for  development  instead 
of  Ada,  but  did  not  obtain  a  waiver.  DoD  Directive  3405.1  requires  that  Ada 
be  used  for  the  development  language  unless  a  waiver  is  approved.  Therefore, 
replanning  is  needed  to  allow  for  its  lower  development  productivity. 

The  RCAS  PMO  has  insufficient  funding  planned  for  development  in  Ada.  The 
Ada  development  productivity  is  5  times  less  than  that  for  the  language  planned. 
The  underestimate  is  $150  million.  In  addition,  the  maintenance  plan  for 
changing  requirements  was  underestimated  by  12,000  FP.  This  underestimate  is 
$12.1  million.  The  combined  development  and  maintenance  underestimate  is 
about  $160  million. 

The  PMO  must  replan  RCAS  to  allow  for  the  lower  development  productivity 
of  Ada  and  the  estimated  additional  costs,  or  obtain  a  waiver. 


Management  Comments  on  the  Finding  and  Evaluation 
Response 


National  Guard  Bureau  Comments.  The  National  Guard  nonconcured  with 
the  finding,  stating  that  the  RCAS  fully  complies  with  the  DoD  Ada  policy. 
The  RCAS  PMO  interpreted  the  selected  4GL  as  an  advanced  software 
technology  (AST).  Ada  policy  treats  ASTs  with  preference  over  Ada.  The 
ASD(C3I)  agreed  with  the  RCAS  program  office's  approach  in  selecting  a  4GL 
in  a  letter  dated  June  14,  1996,  responding  to  our  draft  report.  Additionally, 
based  on  the  evaluation  report,  the  PMO  identified  $10  million  to  be  used  for 
Ada  development  when  required.  Responding  to  the  $12.1  million  maintenance 
shortfall,  the  Guard  stated  that  it  had  planned  for  maintenance  and  software 
growth  and  that  this  amount  would  be  less  than  had  Ada  been  used. 

Assistant  Secretary  Comments.  The  ASD(C3I)  nonconcured  with  the  finding 
in  a  separate  memorandum  of  July  12,  1996.  The  ASD(C3I)  explained  its 
rationale  for  not  requiring  an  Ada  waiver  by  stating  that  the  RCAS  program  was 
in  compliance  with  existing  policy.  Further,  the  ASD(C3I)  concluded  that  the 
RCAS  program  office  did  an  acceptable  assessment  of  productivity  gains,  cost 
avoidance,  and  risk.  The  ASD(C3I)  also  concluded  that  the  program  office 
selected  a  development  strategy  in  line  with  acquisition  reform  and  commercial 
best  practices.  Additionally,  as  the  Major  Automated  Information  System 
Review  Council  Chairman,  the  ASD(C3I)  will  ensure  RCAS  develops  all 
custom  software  in  accordance  with  DoD  Directive  3405.1,  "Computer 
Programming  Language  Policy,"  April  2,  1987. 
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Evaluation  Response.  The  finding  was  based  on  strong  evidence  that  custom 
application  development  using  the  selected  4GL  requires  hands-on  programming 
in  the  embedded  third-generation  language  (3GL).  Application  software 
development  using  this  3GL  language  without  a  waiver  would  be  a  violation  of 
policy. 

The  National  Guard  has  designated  the  4GL  as  a  COTS  AST,  which  the 
regulation  favors  over  Ada  and  which  does  not  require  a  waiver.  The  National 
Guard's  interpretation  was  supported  by  the  ASD(C3I)  which  satisfies  the 
regulatory  issues  of  Finding  A.  However,  the  designation  of  the  4GL  as  an 
AST  avoids  consideration  of  the  embedded  programming  language  usage  risks 
and  life-cycle  cost  impact.  Although  the  RCAS  PMO  provided  assurances  that  it 
will  use  Ada  and  not  the  imbedded  3GL  for  any  procedural  language  coding 
requirements,  the  decision  to  approve  and  use  the  4GL  language  increases  the 
supportability  risk.  The  4GLs  have  greater  risk  than  Ada  in  such  areas  as 
maintainability,  portability,  reliability,  reusability,  and  clarity  of  source  code. 
Also,  the  National  Guard  did  not  adequately  address  the  $12.1  million  shortfall 
calculated  for  software  maintenance,  since  the  problem  stemmed  from  a 
calculation  error,  not  a  difference  in  language  or  development  methodology. 
See  Appendix  D  for  more  detailed  discussion  of  the  report  comments. 


Recommendations,  Management  Comments,  and  Evaluation 
Response 


Deleted  and  Redirected  Recommendations.  In  light  of  the  approval  action  by 
ASD(C3I),  we  withdrew  Recommendation  A.l.a.(l).  to  cease  development  if 
Ada  is  selected.  Instead,  we  directed  recommendations  to  the  Major  Automated 
Information  System  Review  Council  to  monitor  and  periodically  assess  the 
RCAS  program  development  progress.  Because  timeboxes  are  the  basic  unit  of 
software  development,  productivity  at  that  level  is  necessary  to  ensure  that 
specific  development  problems  do  not  get  buried  by  averages  for  the  program. 
Complete  management  comments  are  in  Part  III. 

A.l.  We  recommend  that  the  Chief,  National  Guard  Bureau: 

a.  Cease  further  data  and  applications  development  efforts  until  the 
following  actions  are  completed. 

(1) .  Select  Ada  (or  other  approved  computer  language)  as 
required  by  DoD  Directive  3405.1,  "Computer  Programming  Language 
Policy,"  April  2,  1987,  before  the  project  is  overcommitted  to  a  fourth- 
generation  language. 

(2) .  Reestimate  the  cost  and  schedule  of  the  project  based  on 
realistic  development  productivity  and  maintenance  sizing  or  rescope  the 
Data  and  Applications  functions  to  fit  the  available  cost  and  schedule. 
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National  Guard  Bureau  Comments.  The  National  Guard  nonconcured  with 
Recommendation  A.l.  stating  that  the  RCAS  is  in  full  compliance  with  the  DoD 
Ada  policy.  Conservative  costs  and  schedules  have  been  proposed  based  on 
industry  productivity  data  using  4GLs. 

Evaluation  Response.  Prompt  action  by  the  RCAS  PMO  to  obtain  the 
ASD(C3I)  interpretation  of  the  policy  resulted  in  a  determination  of  compliance. 
However,  the  additional  $12.1  million  for  software  maintenance  is  a  minimum 
and  should  be  recalculated  by  the  RCAS  PMO. 

b.  Require  full  justification,  including  a  life-cycle  cost  analysis  and 
a  risk  analysis  that  addresses  technical  performance  and  schedule  impact,  if 
an  Ada  waiver  is  proposed. 

National  Guard  Bureau  Comments.  The  National  Guard  nonconcured, 
stating  that  an  Ada  waiver  will  not  be  proposed  for  RCAS.  The  RCAS  Program 
Management  Office  stated  that  it  reviewed  the  life-cycle  costs  and  it  established 
a  risk  management  program  that  addresses  technical  performance  and  schedule 
impacts. 

Evaluation  Response.  Prompt  action  bv  the  RCAS  PMO  in  submitting  cost 
and  risk  management  data  to  the  ASDCC^I)  and  obtaining  the  endorsement  of 
the  program's  FY  1996  approach  meets  the  intent  of  our  recommendation. 

c.  Cease  the  more  than  $2  million  procurement  of  Structured  Query 
Language  server  and  the  selected  fourth-generation  language  products 
planned  for  FY  1996,  unless  an  Ada  waiver  is  granted  and  pilot 
applications  are  completed  successfully. 

National  Guard  Bureau  Comments.  The  National  Guard  partially  concurred. 
Since  RCAS  is  in  compliance  with  the  DoD  Ada  policy,  the  PMO  will  continue 
to  acquire  COTS  development  tools  as  planned  for  FY  1996. 

Evaluation  Response.  Prompt  action  by  the  RCAS  PMO  to  obtain  the 
ASD(C3I)  approval  of  the  policy  resulted  in  a  determination  of  compliance. 
This  step,  along  with  progress  made  in  the  pilot  applications,  meets  the  intent  of 
our  recommendation. 

A.2.  We  recommend  that  the  Assistant  Secretary  of  Defense  (Command, 
Control,  Communications,  and  Intelligence),  as  the  chairman  of  the  Major 
Automated  Information  System  Review  Council: 

a.  Monitor  and  periodically  assess  the  Reserve  Component 
Automation  System  software  development  risk  management  with  a  view  to 
identifying  and  correcting  variances  in  a  timely  manner  by  tracking: 

(1) .  Planned- versus-actual  function  points  completed. 

(2) .  Planned-versus-actual  function  point  productivity  by 
completed  timebox. 
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b.  Ensure  that  any  custom  software  development  be  accomplished 
in  accordance  with  the  policies  in  DoD  Directive  3405.1,  "Computer 
Programming  Language  Policy." 
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Finding  B.  Telecommunications  Requirements  and 
Funding 

Specific  telecommunications  requirements  for  equipment  and  services  for 
the  RCAS  program  have  not  been  established  and  total  communications 
costs  are  unknown  and  undetermined.  The  RCAS  Program  Management 
Office  (PMO)  did  not  adequately  determine,  validate,  or  document 
telecommunications  equipment  and  services  requirements.  Further,  the 
RCAS  PMO  did  not  prepare  site  surveys  in  a  manner  to  identify  and 
validate  the  cost  of  preparing  each  site  for  the  installation  of 
telecommunications  equipment  and  services.  Telecommunications  costs 
for  RCAS  are  unknown  because  the  RCAS  PMO  did  not  develop 
documented  requirements  to  support  the  implementation  of  a 
telecommunications  plan.  As  a  result,  the  RCAS  PMO  is  unable  to 
prepare  a  telecommunications  management  plan  to  obtain  the  most  cost- 
effective  telecommunications  circuit  configuration  and  is  unable  to 
determine  the  total  cost  of  the  telecommunications  portion  of  the  RCAS 
program. 


Background 


The  RCAS  system  was  planned  for  deployment  at  4,021  sites,  to  10,540  units, 
and  included  the  installation  of  56,194  workstations.  However,  the  program  has 
funds  available  to  purchase  46,194  workstations  split  between  the  components. 
Printer  or  personal  computer  requirements  exceeding  the  total  number  provided 
by  RCAS  will  be  the  responsibility  of  the  components.  Table  1  shows  the 
Small  Site  (those  with  16  or  fewer  workstations)  and  Large  Site  (those  with  17 
or  more  workstations)  composition  for  sites,  units,  and  workstations: 

Table  1.  RCAS  Workstation  Distribution 


Small 

Site 

Site 

Percentage 

Large 

Site 

Site 

Percentage 

Total 

Sites 

3,262 

81.0 

759 

19.0 

4,021 

Units 

5,223 

49.5 

5,317 

50.5 

10,540 

Work¬ 

stations 

17,936 

32.0 

38,258 

68.0 

56,194 
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RCAS  Telecommunications  Requirements.  The  baseline  of  existing 
telecommunications  equipment  and  services  for  RCAS  was  not  established  and 
validated.  Neither  the  RCAS  PMO  nor  the  vendor: 

o  identified  the  number  of  subscribers, 

o  determined  proposed  user  requirements  for  future  telecommunications 
equipment  and  services  for  each  site,  or 

o  assessed  the  validity  of  proposed  user  requirements  to  establish  a 
telecommunications  configuration  management  plan. 

The  RCAS  PMO  office  rationale  used  to  determine  the  quantity  of 
telecommunications  equipment  and  services  resulted  in  an  inadequate 
identification  of  requirements.  Because  of  cost  constraints,  the  requirements 
were  established  based  on  assumptions  and  on  "recommended"  minimum 
number  of  workstations  for  a  type  unit  rather  than  mission  requirements  or 
priorities.  Therefore,  the  RCAS  PMO  and  the  vendor  were  unable  to  prepare  a 
documented  and  comprehensive  telecommunications  plan. 


Vendor  Approach 


Design-To-Cost  Strategy.  The  single  overriding  requirement  for  the  RCAS 
was  a  design-to-cost  constraint  imposed  on  the  functional  design  of  the  system. 
As  a  result,  some  detailed  requirements  are  not  met  or  are  only  partially  met. 
For  example,  the  requirement  to  allow  100  percent  growth  (quick  expandability) 
in  the  quantity  of  users  with  no  degradation  of  service  will  not  be  met. 

Design-to-cost  resulted  in  the  shifting  of  responsibility  for  many  technical 
support  functions  such  as  site  preparation  of  telecommunications  hubs,  circuit 
ordering,  and  site  local  area  network  (LAN)  wiring  for  small  sites,  from  the 
vendor  to  the  Army  Reserve  and  National  Guard  Commands.  However,  those 
Commands  may  not  have  the  expertise  and  resources  necessary  to  perform  those 
functions. 

Further,  because  specific  requirements  for  telecommunications  equipment  and 
services  have  not  been  established,  the  RCAS  PMO  has  been  unable  to 
determine  actual  telecommunications  costs.  According  to  the  RCAS  PMO,  new 
program  costs,  schedules,  and  technical  baselines  were  to  be  established  during 
third  quarter  FY  1996  through  user  test  and  pilot  programs. 

Site  Surveys.  Site  surveys  were  not  conducted  at  each  location  to  obtain  a  valid 
estimate  for  the  installation  cost  of  telecommunications  equipment  and  services 
for  RCAS.  Detailed  site  preparation  cost  data  for  each  RCAS  site  were  not 
obtained.  The  RCAS  PMO  and  the  vendor  failed  to  require  sites  to  provide  cost 
data  for  needed  improvements  through  the  site  survey  process.  A  total  of  2,400 
National  Guard  and  Army  Reserve  units  have  already  been  prepared  and  LANs 
installed  under  the  old  RCAS  solution.  The  actual  cost  of  LAN  drops,  electrical 
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power  modifications,  circuit  scheduling,  and  physical  plant  improvements 
necessary  to  prepare  the  remaining  8,140  units  (or  77  percent)  for  RCAS  is 
unknown. 

Proper  site  surveys  are  essential  to  identify  requirements  such  as: 

o  electrical  or  LAN  requirements; 

o  the  need  to  install  electrical  and  LAN  wiring  (to  include  ancillary 
equipment  such  as  patch  panels,  racks,  and  cabinets); 

o  the  need  for  upgrades  within  buildings  and  site  main  service 
distribution  panelboards; 

o  the  need  for  improvements  in  building  and  site  power  quality  or 
reliability; 

o  the  need  to  upgrade  existing  electrical  utilities  and  grounding  systems 
to  meet  National  Electric  Code  requirements;  and 

o  the  need  to  furnish  and  install  and  upgrade  existing  heating, 
ventilation,  and  air  conditioning  as  required. 


Summary 


As  the  result  of  the  uncertainty  of  program  requirements,  the  total  cost  for 
RCAS  installation  and  telecommunications  may  be  underfunded.  The  RCAS 
PMO  and  the  vendor  failed  to: 

o  establish  a  baseline  of  existing  telecommunications  equipment  and 
services; 

o  validate  requirements  for  existing  telecommunications  equipment  and 
services; 

o  obtain  documented  requirements  for  telecommunications  services  by 
identifying  the  number  of  subscribers,  determining  proposed  user  requirements 
for  future  telecommunications  services,  assessing  the  validity  of  such  proposed 
requirements,  and  developing  a  telecommunications  configuration  management 
plan  based  on  validated  proposed  user  requirements;  and 

o  conduct  site  surveys  to  determine  the  total  cost  of  telecommunications 
equipment,  services,  and  facilities  necessary  to  install  RCAS  at  the  remaining 
sites. 
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Recommendations,  Management  Comments,  and  Evaluation 
Response 


B.  We  recommend  that  the  Reserve  Component  Automation  System 
Program  Manager  cease  further  procurement  of  telecommunications 
services  and  equipment  for  the  Reserve  Component  Automation  System 
program  until: 

1.  The  Reserve  Component  Automation  System  Program 
Management  Office  establishes  a  baseline  of  existing  telecommunications 
equipment  and  services  and  validates  requirements  for  existing 
telecommunications  equipment  and  services. 

2.  The  Reserve  Component  Automation  System  Program 

Management  Office  identifies  the  number  of  subscribers,  determines 
proposed  user  requirements  for  future  telecommunications  equipment  and 
services  for  each  site,  assesses  the  validity  of  proposed  user  requirements, 
and  establishes  a  telecommunications  configuration  management  plan  based 
on  validated  proposed  user  requirements. 

3.  The  Reserve  Component  Automation  System  Program 

Management  Office  conducts  site  surveys  to  determine  the  total  cost  of  the 
telecommunications  equipment  and  services  portion  of  the  Reserve 
Component  Automation  System  program. 

4.  The  Reserve  Component  Automation  System  Program 

Management  Office  projects  budgetary  costs  for  the  telecommunications 
equipment  and  services  portion  of  the  Reserve  Component  Automation 
System  program  and  establishes  a  funding  program  for  the  Army  Reserve 
Components. 

Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence)  Comments.  The  Assistant  Secretary  partially  concurred  with 
Recommendations  B.I.,  B.2.,  and  B.4.  but  nonconcurred  with  Recommendation 
B.3.  The  Assistant  Secretary  stated  that  at  the  time  of  the  evaluation,  the  draft 
telecommunications  plan  lacked  some  of  the  required  substantive  details.  The 
Assistant  Secretary  stated  that  the  Defense  Information  Systems  Agency  is 
responsible  for  validating  the  proposed  telecommunications  architecture  and 
ensuring  compliance  with  DoD  telecommunications  policies,  including 
consistency  and  conformance  with  the  Defense  Information  Systems  Network, 
transition  to  the  Defense  Messaging  System,  and  conformance  with  the  DoD 
Technical  Architecture  for  Information  Management.  The  Assistant  Secretary 
further  stated  that,  to  obtain  approval  from  his  office,  the  Telecommunications 
Plan  must  describe  the  functional  telecommunications  requirements,  definition 
of  responsibilities,  detailed  network  description,  all  network  interfaces,  and 
traffic  workload  characteristics  and  that  a  RCAS  Telecommunications  Plan  must 
be  approved  by  his  office  before  Major  Automated  Information  System  Review 
Council  approval  for  deployment.  Additionally,  the  Assistant  Secretary  stated 
that  the  Army  National  Guard  and  U.S.  Army  Reserves  have  agreed  on  the 
revised  Telecommunications  Plan  and  the  prioritization  of  requirements  and  the 
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RCAS  will  use,  with  Defense  Information  Systems  Agency  approval,  excess 
capacity  on  other  networks  provisioned  by  the  Army  National  Guard  and  U.S. 
Army  Reserves. 

Evaluation  Response.  At  the  time  of  our  evaluation,  the  RCAS  PMO  prepared 
only  a  draft  Telecommunications  Plan  that  was  incomplete  and  missing 
substantive  elements  of  operational  requirements,  baseline  cost,  and 
configuration  management  data.  Therefore,  we  were  unable  to  certify  the 
viability  of  the  new  restructured  RCAS.  Also,  at  the  time  of  our  evaluation,  the 
Reserve  Component  Automation  System  Program  Management  Office  stated 
that  new  program  costs,  schedules,  and  technical  baselines  would  be  established 
during  third  quarter  FY  1996  through  user  test  pilots.  However,  because  of 
time  constraints  to  perform  this  evaluation,  we  did  not  assess  the  results  of  the 
pilot  test  to  determine  whether  the  deficiencies  noted  were  corrected.  Although 
the  Assistant  Secretary  partially  concurred  with  Recommendations  B.I.,  B.2., 
and  B.4.,  we  consider  die  requirements  the  Assistant  Secretary  established  for 
an  approved  Telecommunications  Plan,  Defense  Information  Systems  Agency 
validation  of  the  telecommunications  architecture,  and  Major  Automated 
Information  System  Review  Council  approval  for  deployment  to  meet  the  intent 
of  our  recommendations. 

Although  the  Assistant  Secretary  did  not  concur  with  Recommendation  B.3., 
concerning  the  need  for  the  RCAS  PMO  to  conduct  site  surveys,  we  consider 
that  the  actions  taken  subsequent  to  our  evaluation  meet  the  intent  of  the 
recommendation. 

National  Guard  Bureau  Comments.  The  Chief,  National  Guard  Bureau, 
partially  concurred  with  Finding  B  and  nonconcurred  with  the 
recommendations.  The  Chief  stated  that  the  finding  was  partially  accurate  at  the 
time  that  the  evaluation  was  performed  and  that  the  Telecommunications  Plan 
has  been  rewritten  and  submitted  to  the  Defense  Information  Systems  Agency, 
Army  organizations,  and  the  Office  of  the  Assistant  Secretary  of  Defense 
(Command,  Control,  Communications,  and  Intelligence)  for  approval.  The 
Chief  stated  that  the  fully  completed  and  staffed  plan  would  be  presented  at  the 
Major  Automated  Information  System  Review  Council  Milestone  III  decision 
briefing  during  the  fourth  quarter  FY  1996. 

Concerning  Recommendation  B.I.,  the  Chief  stated  that  the  baseline  of  RCAS 
telecommunications  was  documented  in  the  Telecommunications  Plan  by  the 
circuits  installed  during  Phase  II  of  the  contract.  Concerning  Recommendation 
B.2.,  the  Chief  stated  that  telecommunication  requirements  were  established  by 
Customer  Focus  Team  representatives  to  the  Validation  Assessment  Team. 
Concerning  Recommendation  B.3.,.  the  Chief  stated  that  the  cost  for 
telecommunications  equipment  is  in  the  total  hardware  cost  for  the  RCAS  and 
that  telecommunications  services  costs  have  been  programmed  over  the  life  of 
the  RCAS  contract,  using  several  fielding  scenarios,  which  indicate  a  total  cost 
estimate  of  $53  million.  Concerning  Recommendation  B.4.,  the  Chief  stated 
that  budgetary  costs  for  telecommunications  equipment  and  services  are  in  the 
RCAS  Program  Operating  Budget. 
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Evaluation  Response.  As  stated  in  the  response  to  the  Assistant  Secretary's 
comment,  the  RCAS  Program  Office  prepared  only  a  draft  Telecommunications 
Plan  that  was  incomplete  and  missing  substantive  elements  of  operational 
requirements,  baseline  cost,  and  configuration  management  at  the  time  of  our 
evaluation.  Based  on  this  missing  information,  we  were  unable  to  certify  the 
viability  of  the  new  restructured  RCAS.  Also  at  the  time  of  our  evaluation,  the 
RCAS  PMO  stated  that  new  program  costs,  schedules,  and  technical  baselines 
would  be  established  during  third  quarter  FY  1996  through  user  test  pilots. 

Although  the  Chief  nonconcurred  with  our  recommendations,  the  intent  of  our 
recommendations  will  be  achieved  by  the  actions  taken  and  the  actions  proposed 
by  the  Assistant  Secretary.  The  requirements  established  by  the  Assistant 
Secretary  for  an  approved  Telecommunications  Plan,  Defense  Information 
Systems  Agency  validation  of  the  telecommunications  architecture,  the  Major 
Automated  Information  System  Review  Council  review,  and  the  other  actions 
taken  subsequent  to  our  evaluation  meet  the  intent  of  the  recommendations. 
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Infrastructure  Budget  Risks 

Budgeted  funds  to  purchase  the  RCAS  COTS  infrastructure  (personal 
computers,  office  automation  software,  and  telecommunications)  are  at 
risk  from  other  areas  of  the  program  that  are  underbudgeted.  The  RCAS 
program  has  year-to-year  imbalances  of  Other  Procurement-Army  (OP A) 
funds  needed  to  finance  the  Boeing  contract.  Additionally,  as  stated  in 
Findings  A  and  B,  the  RCAS  PMO  has  underestimated  software 
development  and  has  not  determined  telecommunications  costs. 
Insufficient  infrastructure  investment  could  force  the  Army  National 
Guard  and  Army  Reserve  units  to  wait  more  than  6  years  for  the 
anticipated  benefits  from  deploying  the  RCAS  commercial  off-the-shelf 
infrastructure. 


Reserve  Component  Information  Requirements 


Reserve  Component  mobilization  is  the  second  highest  priority  among  the 
Army's  missions.  All  other  missions  must  support  contingency  operations  and 
mobilization.  The  purpose  of  mobilization  is  to  provide  mission-capable  units 
to  operational  commanders.  The  Reserve  Component  manages  the  mobilization 
support  information  by  gathering  and  maintaining  unit  administration  data 
during  peacetime  and  generating  mobilization  data  during  mobilization 
execution. 

The  Army  and  its  Reserve  Component  decisionmakers  must  be  able  to 
effectively  manage  the  resources  supporting  readiness  and  mobilization 
preparedness.  The  capability  is  directly  related  to  the  availability  of 
information.  The  existing  Army  National  Guard  and  Army  Reserve  information 
systems  are  unable  to  provide  timely  and  accurate  information  to  decision¬ 
makers  to  allow  either  mobilization  planning  or  execution  to  be  conducted  as 
required  to  meet  contingency  plans. 

Delays  in  the  RCAS  program  caused  the  Army  National  Guard  and  Army 
Reserve  unit  deficiencies  in  needed  computer  resources.  The  controls  imposed 
by  the  National  Guard  Bureau  and  U.S.  Army  Reserve  Command  regulated  the 
procurement  of  computers  for  FYs  1988  through  1995.  The  controls 
implemented  congressional  restrictions  that  were  stated  in  Defense 
Appropriations  Acts  and  public  law.  The  Army  National  Guard  and  Army 
Reserve  units  need  the  RCAS  COTS  infrastructure  to  perform  their  day-to-day 
administrative  functions.  The  Army  National  Guard  and  Army  Reserve  units 
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must  often  manually  compile  information  requested  by  commanders  and  higher 
headquarters.  Additionally,  updating  information  is  time-  and  manpower¬ 
intensive  and,  therefore,  is  often  not  done  as  frequently  as  needed. 

Due  to  the  important  need  to  provide  timely  and  accurate  information  and  to 
improve  the  accomplishment  of  administrative  tasks,  the  Army  National  Guard 
and  the  Army  Reserve  requested  that  the  PMO  RCAS  field  the  RCAS  COTS 
infrastructure  within  3  years.  Additionally,  the  General  Officer  Steering 
Committee  endorsed  the  Army  National  Guard  and  Army  Reserve  requests  by 
recommending  that  the  PMO  RCAS  pursue  a  high-level  fielding  strategy  for 
FYs  1996  through  1998.  However,  the  current  program  schedule  still  spreads 
the  delivery  of  die  RCAS  COTS  infrastructure  to  the  Army  National  Guard  and 
the  Army  Reserve  over  7  years  due  to  funding  constraints. 


RCAS  COTS  Infrastructure 


The  RCAS  program  restructure  allowed  change  of  the  program  direction  to 
leverage  new  information  management  technology,  improve  user  support,  and 
meet  users'  requirements.  The  new  design  integrates  COTS  data  processing 
capabilities  for  office  automation  and  electronic  mail.  These  COTS  products 
fortn  the  infrastructure  for  the  development  of  the  RCAS  functionality.  The 
Data  and  Applications  software  development  will  provide  the  automation  of  the 
functional  processes.  The  infrastructure  design  expands  around  personal 
computer-based  workstations  connected  to  servers  via  LAN  communication. 
The  LAN  segments  are  connected  to  the  higher  command  levels  of  the  Reserve 
Component  either  by  dedicated  or  dial-in  communications.  The  site 
infrastructures  are  sized  to  meet  the  different  units'  requirements. 

The  RCAS  COTS  infrastructure  alone,  without  the  developed  software,  fully  or 
partially  meets  51  of  the  71  user-defined  operational  and  program  requirements 
that  remained  after  eliminating  non-system  requirements  and  requirements  not 
met  due  to  design-to-cost  constraints.  We  did  not  identify  the  relative 
importance  of  each  of  the  requirements. 

The  current  requirements  for  COTS  hardware,  software,  and 
telecommunications  are  budgeted  for  by  the  RCAS  PMO  and  are  the  result  of 
the  program  funding  constraints.  Although  a  faster  RCAS  COTS  infrastructure 
deployment  plan  was  desired,  the  Army  National  Guard  and  Army  Reserve, 
through  the  General  Officer  Steering  Committee,  accepted  the  budgeted  7-year 
delivery  schedule. 


Budget  Risks 


To  meet  the  COTS  infrastructure  delivery  schedule,  the  RCAS  PMO  must 
manage  the  risk  associated  with  the  OPA  budget  imbalances  and  funding 
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shortfalls  from  previous  findings.  The  RCAS  PMO  budget  currently  contains 
shortages  between  yearly  OP  A  funds  and  yearly  contract  commitments.  Also, 
the  conditions  discussed  in  Findings  A  and  B  may  cause  additional  risk  to  funds 
designated  for  delivery  of  the  COTS  infrastructure. 

The  RCAS  Program  has  $1.06  billion  in  its  Program  Objective  Memorandum 
budget  with  which  to  provide  the  Army  National  Guard  and  Army  Reserve  the 
RCAS  system.  The  funding  profile  includes  both  OP  A  and  Operations  and 
Maintenance  (O&M)  funds.  Table  2  shows  the  RCAS  Program  Objective 
Memorandum  funds  for  FYs  1996  through  2003;  carryover  fimds  from  FY 
1995  are  also  included. 


Table  2.  POM  Funding  Profile 

(in  millions  of  dollars) 

_ FY _ 


95 

96 

92 

98 

99 

00 

Qi 

02 

03 

Total 

OPA 

60.6 

80.6 

72.6 

108.7 

100.3 

69.5 

73.6 

75.2 

76.8 

717.9 

O&M 

0.0 

35.8 

36.7 

45.7 

42.2 

42.4 

43.7 

44.7 

45.6 

336.8 

The  RCAS  PMO  renegotiated  the  Boeing  contract  as  part  of  the  program 
restructure  and  implemented  the  modification  February  1,  1996.  The  program 
restructure  also  changed  the  basic  contract  structure.  Specifically,  the  contract 
moved  from  a  hybrid  cost-plus-award-fee  and  fixed-price  with  an  award  fee 
contract  to  a  new  structure  that  has  three  components.  The  core  effort  of  the 
contract  will  be  done  on  a  cost-plus-award-fee  basis;  software  development  will 
be  performed  on  a  fixed  rate,  time  and  materials  basis;  and  COTS  hardware  and 
COTS  software  will  be  purchased  on  an  indefinite  delivery/indefinite  quantity 
basis. 

OPA  Budget  Imbalances.  The  restructured  Boeing  OPA  contract  value  is 
$716.7  million.  The  RCAS  Program  OPA  funding  for  FYs  1996  through  2003 
is  $717.9  million. 


Table  3.  Current  Yearly  OPA  Shortfalls 

(in  millions  of  dollars) 


FY 


95 

96 

92 

98 

99 

OPA 

Funding  60.6 

80.6 

72.6 

108.7 

100.3 

Boeing 

Contract 

0T) 

59.0 

95.2 

98.0 

118.3 

Differ¬ 

ence 

60.6 

21.6 

(22.6) 

10.7 

(18.0) 
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00 

01 

02 

03 

Total 

69.5 

73.6 

75.2 

76.8 

717.9 

124.0 

104.8 

108.8 

8.6 

716.7 

(54.5) 

(31.2) 

(33.6) 

68.2 

1.2 
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Currently,  the  program  has  a  $1.2  million  management  reserve  covering  the  life 
of  the  contract.  However,  year-to-year  OPA  imbalances  exist  between  the  OPA 
POM  funds  and  the  OPA  contract  commitments.  To  decrease  the  year-to-year 
shortage  imbalances,  the  RCAS  PMO  has  submitted  a  request  to  transfer  $94.2 
million  from  O&M  to  OPA.  Table  4  shows  the  resultant  OPA  funding  if  the 
request  is  approved. 

Table  4.  Projected  Yearly  OPA  Shortfalls 

(in  millions  of  dollars) 

_ FY _ 


95 

96 

97 

98 

99 

00 

01 

02 

03 

Total 

OPA 

Contract- 

Difference 

60.6 

21.6 

(22.6) 

10.7 

(18.0) 

(54.5) 

(31.2) 

(33.6) 

68.2 

1.2 

O&M 

0.0 

0.0 

4.5 

7.3 

12.2 

23.5 

25.4 

21.3 

OLO 

94.2 

Differ¬ 

ence 

60.6 

21.6 

(18.1) 

18.0 

(5.8) 

(31.0) 

(5.8) 

(12.3) 

68.2 

95.4 

The  RCAS  PMO  is  aware  that  even  if  the  O&M  to  OPA  request  is  approved, 
imbalances  still  exist  between  yearly  OPA  funds  and  yearly  contract 
commitments.  To  alleviate  this  problem,  the  PMO  plans  to  reallocate  RCAS 
COTS  infrastructure  funds  and  fielding  funds  between  the  program  years  to 
meet  the  OPA  funding  profile.  The  reallocation  would  result  in  the  reduction  of 
RCAS  COTS  infrastructure  procurement  to  meet  the  yearly  available  funding 
profile. 

Although  FY  2003  has  a  $68.2  million  management  reserve,  FYs  1999  to  2002 
have  funding  imbalance  shortfalls.  Additionally,  even  though  reallocation  of 
funds  is  common  practice,  the  reallocation  jeopardizes  the  current  fielding  plan 
for  the  RCAS  COTS  infrastructure. 

In  addition  to  the  $1.06  billion  in  RCAS  Program  funds,  under  the  RCAS 
program  restructure,  the  Army  National  Guard  and  Army  Reserve  have  been 
asked  to  provide  additional  O&M  funds  to  cover  costs  previously  budgeted  for 
RCAS  PMO  funds.  Starting  in  FY  1998,  the  Army  National  Guard  and  the 
Army  Reserve  will  pay  for  RCAS  telecommunications,  cable  modernization, 
consumables,  replacement  training,  COTS  software  maintenance,  and  additional 
COTS  hardware  maintenance.  Therefore,  the  Army  National  Guard  and  the 
Army  Reserve  have  requested  $235.3  million  in  their  Program  Objective 
Memorandum  for  FYs  1998  through  2003  to  cover  RCAS  O&M  costs.  Neither 
the  Army  National  Guard  nor  the  Army  Reserve  earmarked  funds  for  RCAS 
O&M  in  FYs  1996  and  1997. 
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Funding  Shortfalls  Discussed  in  Findings  A  and  B.  The  impact  of  the 
problems  discussed  under  Findings  A  and  B  could  negatively  impact  the  OPA 
budget  requirements.  Often,  contract  requirements  considered  variable  and 
acceptable  for  reallocation  are  later  identified  as  areas  that  can  be  cut  to  meet 
actual  funding  amounts.  Additionally,  as  stated  in  Finding  A,  software 
development  productivity  and  cost  are  significantly  underestimated.  Further,  as 
stated  in  Finding  B,  telecommunications  costs  are  unknown  and  undetermined. 
Consequently,  funds  for  the  RCAS  COTS  infrastructure  may  be  used  to  finance 
the  core  contract  or  software  development. 


Additional  Computer  Resources 


Additional  computer  systems  within  the  Reserve  Component  could  be  used  to 
expand  the  RCAS  infrastructure  to  other  users.  The  RCAS  PMO  will  upgrade 
about  10,000  of  the  existing  computers  to  meet  current  delivery  requirements 
within  available  funding.  Also,  other  programs  have  provided  automated  data 
processing  equipment  to  support  specific  functions.  On  May  16,  1996,  the 
Inspector  General,  DoD,  issued  evaluation  Report  No.  96-121,  "Army  Reserve 
Component  Procurement  of  Computers."  The  report  identified  an  additional 
16,000  computers  that  could  meet  the  RCAS  workstation  requirements.  Efforts 
should  be  made  to  ensure  that  multiple  use  of  all  existing  systems  is  considered 
to  further  support  the  Reserve  Component  users.  However,  the  16,000 
computers  should  not  be  construed  as  replacement  systems  for  the  computer 
systems  planned  for  delivery  under  the  RCAS  program. 


Summary 


Budgeted  funds  designated  to  the  delivery  of  the  RCAS  COTS  infrastructure  for 
the  Reserve  Component  units  are  at  risk.  Year-to-year  OPA  funding  imbalances 
produce  funding  risks  to  the  RCAS  COTS  infrastructure.  FYs  1999  to  2002 
have  funding  imbalance  shortfalls.  Additionally,  as  discussed  in  Finding  A,  the 
RCAS  PMO  underestimated  software  development  costs  and  did  not  fully 
determine  telecommunications  costs.  Therefore,  the  risk  to  RCAS  funding 
increases  by  $160  million  for  software  development  and  is  unknown  for 
telecommunications.  The  Army  and  its  Reserve  Component  decisionmakers 
must  be  able  to  effectively  manage  the  resources  supporting  readiness  and 
mobilization  preparedness.  This  capability  is  directly  related  to  the  availability 
of  information.  To  meet  this  need,  the  RCAS  COTS  infrastructure  needs  to  be 
fielded.  Transferring  and  using  RCAS  COTS  infrastructure  funds  for  other 
requirements  is  not  an  acceptable  option. 
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Management  Comments  on  the  Finding  and  Evaluation 
Response 


National  Guard  Bureau  Comments.  The  National  Guard  Bureau 
nonconcured  with  the  finding,  stating  that  the  actions  discussed  in  Findings  A 
and  B  do  not  appear  to  be  a  cause  of  additional  funding  risks.  The  PMO  has 
requested  a  funding  realignment  to  correct  the  OPA  funding  imbalance  and  to 
meet  the  needs  of  the  contract.  The  Bureau  also  reiterated  that  the  funding 
profile  dictated  the  fielding  approach. 

The  PMO  is  attempting  to  modify  the  fielding  strategy  within  the  funding 
profile  to  reach  as  many  Army  Reserve  National  Guard  and  U.S.  Army  Reserve 
users  as  early  as  possible.  The  PMO  actions  to  accomplish  this  early  fielding 
include  retrofitting  the  entire  old  RCAS  equipment,  modifying  the  Government- 
furnished  personal  computers,  and  installing  communications  hubs  at  all  major 
commands. 

Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence)  Comments.  The  ASD(C3I)  concurred  with  the  finding,  stating 
that  the  Army  has  adjusted  the  funding  in  the  Program  Objective  Memorandum 
to  align  with  current  program  requirements. 

Evaluation  Response.  The  National  Guard  Bureau  comments  are  responsive  to 
the  finding.  The  cumulative  effect  of  ASD(C3I)  approval  of  the  language 
selection  and  the  risk  management  programs  satisfy  the  intent  of  Finding  C  with 
respect  to  program  resources. 


Recommendations,  Management  Comments,  and  Evaluation 
Response 


C.  We  recommend  that  the  Chief,  National  Guard  Bureau: 

1.  Formally  baseline  the  Reserve  Component  Automation  System 
commercial  off-the-shelf  hardware  and  software  infrastructure  delivery 
schedule  and  quantities. 

National  Guard  Bureau  Comments.  The  Bureau  concurred  and  continued  to 
finalize  the  Acquisition  Program  Baseline  for  the  DoD  Major  Automated 
Information  System  Review  Council  Milestone  III  decision  briefing,  which  was 
scheduled  for  the  fourth  quarter  of  FY  1996. 
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Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence)  Comments.  The  ASD(C3I)  concurred  and  stated  that  the  National 
Guard  submitted  the  second  draft  of  the  Acquisition  Program  Baseline  required 
by  DoD  5000. 2-R  on  June  28,  1996.  Following  the  inclusion  of  final 
comments,  the  Acquisition  Program  Baseline  will  be  staffed  for  the  Milestone 
Decision  Authority  approval. 

Evaluation  Response.  The  actions  are  responsive  to  our  recommendation. 

2.  Ensure  that  multiple  use  of  existing  computer  systems  is 
considered  to  further  support  the  Reserve  Component  users. 

National  Guard  Bureau  Comments.  The  Bureau  concurred  and  stated  the 
RCAS  solution  will  capitalize  10,000  existing  computer  resources  from  the 
Army  Reserve  National  Guard  and  U.S.  Army  Reserve.  Also,  the  RCAS  PMO 
based  the  solution  on  an  open  architecture  that  allows  each  unit  to  connect  other 
computer  equipment  to  the  RCAS  system. 

Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence)  Comments.  The  ASD(C3I)  concurred  and  stated  the  removal  of 
restrictive  congressional  language  allows  the  Bureau  to  use  existing  resources. 
The  architecture  chosen  by  RCAS  also  allows  interconnection  of  additional 
resources  acquired  by  RCAS  users  because  of  compliance  with  the  Defense 
Information  Infrastructure  Common  Operating  Environment. 

Evaluation  Response.  The  actions  are  responsive  to  our  recommendation. 
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Part  II  -  Additional  Information 


Appendix  A.  Scope  and  Methodology 


We  performed  our  technical  evaluation  of  the  RCAS  Program  from  October 
1995  through  April  1996.  Our  evaluation  focused  on  the  RCAS  Program 
restructure.  Reviewed  documents  were  dated  from  February  1995  through 
April  1996.  We  gathered  data  through  individual  and  group  interviews  and 
analyzed  numerous  documents,  files,  and  records,  including  specifications,  test 
and  evaluation  master  plan  for  operational  testing,  Final  RCAS  Validation 
Assessment  Team  Report,  final  architecture  specification,  customer  focus  team 
report,  proof  of  concept,  software  final  report,  final  sustainment  report, 
reengineering  technical  assessment,  RCAS  concept  of  operation,  RCAS 
deployment  risks  and  abatements,  Operational  Concept  Description,  software 
management  plan,  system  specification,  system  architecture,  system  engineering 
management  plan,  program  budget  data,  and  program  cost  data. 

We  interviewed  the  Program  Manager,  management  staff,  contracting  officer, 
prime  contractor,  and  users  from  the  Army  National  Guard  and  Army  Reserve. 
We  visited  the  Headquarters,  National  Guard  Bureau;  the  Office  of  the  Chief, 
Army  Reserve;  U.S.  Army  Reserve  Command;  and  the  Headquarters,  U.S. 
Forces  Command.  Additionally,  we  visited  Iowa  Army  National  Guard  Units 
and  Army  Reserve  units  in  Pennsylvania  and  Georgia. 

The  evaluation  team  consisted  of  members  of  the  Technical  Assessment 
Division,  Analysis,  Planning,  and  Technical  Support  Directorate,  Office  of  the 
Inspector  General,  DoD.  The  team  members  have  expertise  in  computer 
science,  hardware  and  software  engineering,  auditing,  and  acquisition 
management. 
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Appendix  B.  Prior  Audits  and  Other  Reviews 


The  Inspector  General,  DoD,  published  Report  No.  96-121,  "Army  Reserve 
Component  Procurement  of  Computers,"  dated  May  16,  1996.  The  Army 
Reserve  Component  procured  about  26,000  computers  from  FYs  1991  through 
1995  outside  the  RCAS-funded  program.  The  results  of  the  review  of 
procurement  controls  and  practices  provided  reasonable  assurances  that  during 
FYs  1991  through  1995,  the  Army  National  Guard  and  the  Army  Reserve 
managed  the  procurement  of  modem  computers  in  consonance  with 
congressional  restrictions.  The  National  Guard  Bureau  and  the  Office  of  the 
Chief  of  the  Army  Reserve  provided  guidance  that  accurately  reflected  language 
in  the  Defense  Appropriations  Acts  to  the  purchasing  authority  levels  within  die 
Army  Reserve  Component  structure.  The  evaluation  found  no  evidence  that 
acquisition  actions  by  the  Army  Reserve  Component  violated  laws,  to  include 
the  Anti-Deficiency  Act.  The  report  did  not  contain  recommendations. 

The  Inspector  General,  Department  of  the  Army,  published  "Special  Assessment 
of  the  Reserve  Component  Automation  System,"  dated  August  4,  1994.  The 
report  found  general  agreement  among  Active  and  Reserve  forces  that  an 
automation  system  for  the  Reserve  Components  was  needed.  The  report  also 
found  considerable  risk  involved  in  developing  RCAS.  The  report  stated  that 
congressional  oversight  necessary  to  get  the  program  started  was  too  restrictive 
and  precluded  time  and  monetary  benefits.  The  management  functions  were  not 
optimized  by  the  current  structure,  life-cycle  costs  for  the  RCAS  were  not  kept 
current,  RCAS  electronic  mail  was  slow  and  unreliable,  and  other  office 
applications  were  not  modern  and  were  difficult  to  learn.  The  report  also  states 
that  fielding  of  equipment  was  based  on  the  number  of  full-time  authorizations, 
rather  than  the  actual  number  of  personnel  within  units.  The  assessment  made 
recommendations  to  correct  the  identified  issues. 
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The  RCAS  PMO  lacked  personnel  in  key  positions  and  lacked  Government 
technical  support  for  important  management  control  functions.  Eight  technical 
leadership  positions  were  vacant  in  the  System  Development  Division.  These 
position  responsibilities  include  requirements,  communications,  data 
management,  data  standardization,  automated  data  processing  planning,  and 
system  development.  Additionally,  the  RCAS  PMO  has  no  Central  Design 
Activity,  which  could  provide  contractor- independent  software  technical  advice. 
As  a  result,  there  could  be  an  over-dependency  on  the  contractor  and  the 
program  may  not  be  effectively  and  efficiently  executed. 

In  addition,  the  contractor  is  dependent  on  Government-furnished  information 
and  on  external  interface  agreements.  This  information  includes  documentation, 
data,  software,  and  hardware  for  systems  expected  to  become  part  of  RCAS  as 
GOTS  or  expected  to  be  external  interfaces  to  the  RCAS.  Each  Government- 
furnished  product  or  output  must  be  provided  by  the  Government  one  month 
before  the  beginning  of  the  associated  functional  area  planning  activities. 
Technical  management  in  the  PMO  is  required  for  accurate  and  timely  delivery 
of  such  technical  information.  A  delay  in  Government-furnished  information 
could  negatively  impact  program  cost  and  schedule. 

The  PMO  is  working  closely  with  the  Office  of  Personnel  Management  to  fill 
the  vacant  technical  positions.  Some  of  the  positions  are  military,  and  military 
personnel  have  been  assigned  to  them.  The  PMO  has  acknowledged  the  need 
for  long  term  support  of  RCAS  and  the  value  of  a  Central  Design  Activity. 
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Appendix  D.  Responses  to  Finding  A 
Management  Comments 


The  RCAS  PMO  provided  detailed  management  comments  on  each  section  of 
Finding  A  of  the  draft  Evaluation  Report.  The  following  provides  a  summary 
of  the  RCAS  PMO  comments  and  evaluation  responses. 


Software  Development  Approach 


National  Guard  Bureau  Comments.  The  RCAS  PMO  stated  that  it  "applied  a 
managed  risk  approach  to  software  development,"  using  "advanced  4GL  tools  in 
a  prototyping  environment  with  extensive  user  participation."  The  approach 
also  exploits  both  Government  and  commercial  off-the-shelf  products.  The 
PMO  said  that  "[it]  has  established  metrics  and  risk  management  programs  to 
identify  and  address  potential  problems  before  they  become  critical  program 
issues." 

Evaluation  Response.  We  stand  by  our  original  statement  that  the  funding 
allocated  was  insufficient  to  support  a  system  developed  with  Ada.  We  based 
our  position  on  an  internal  assessment  of  the  program  funding  and  schedule,  the 
COTS  Integration  Approach  Business  Case  portion  of  the  RCAS  Validation 
Assessment  Team  (VAT)  Software  Report,  July  1995. 


Development  Language  Issues 


National  Guard  Bureau  Comments.  The  Evaluation  Report  states  that  coding 
will  be  required  in  the  generated  language.  The  RCAS  PMO  responses  clearly 
disagreed.  They  state  that  "the  selected  4GL  is  predicated  on  the  idea  that  the 
developer  will  employ  the  tool  alone  to  customize  the  user  interface,  processing 
and  application  interfaces.  Code  level  modifications  are  not  involved.  Cases 
that  might  require  code  level  changes  are  facilitated  by  tools  included  in  the 
4GL  package.  These  artifacts  are  simply  'scripts'  comparable  to  Microsoft 
Exec  macros  that  define  formulas,  labels  or  constants  within  the  spreadsheet." 
The  PMO  has  set  aside  $10  million  to  support  functionality  that  would  require 
procedural  language  coding  in  Ada. 

Evaluation  Response.  The  finding  was  based  on  strong  evidence  that  custom 
application  development  using  the  selected  4GL  requires  hands-on  programming 
in  the  embedded  third-generation  language.  That  embedded  third-generation 
language,  PowerScript,  is  a  proprietary,  general  purpose  programming 
language,  not  just  a  macro  language.  PowerBuilder  provides  the  capability  to 
edit  PowerScript  code  for  purposes  of  customizing  applications.  The  ability  to 
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modify  the  code  generated  is  inherent  in  the  product.  The  basis  for  our 
contention  is  the  descriptive  material  provided  by  PowerBuilder  technical 
assistance.  This  material  contains  instructions  and  PowerScript  code  segments 
to  help  develop  custom  functions. 

We  accept  the  PMO  statements  that  the  contractor  will  use  the  selected  4GL  for 
most  of  the  application  development  and  Ada,  not  PowerScript,  for  custom 
coded  functionality.  The  computer  programming  language  generated  by  an 
Advanced  Software  Technology  tool  and  even  edit  access  to  this  generated 
language  is  not  a  violation  of  policy  if  it  is  unused  for  general  purpose 
programming.  However,  it  will  be  difficult  to  enforce  the  PMO  rules  on  the 
contractor  regarding  the  use  of  Ada,  not  PowerScript,  for  writing  development 
code. 

The  PMO  establishment  of  metrics  and  risk  management  programs  is  an 
appropriate  response  to  the  risks  of  a  4GL  development  approach  elaborated  in 
the  Evaluation  Report.  We  are  still  concerned  with  the  up  front  expenditure  of 
$2.2  million  for  Sybase  and  PowerSoft  software.  Its  acquisition  was  not  spread 
over  the  contract  period  like  the  other  COTS  software  (See  Contract  Number 
DAHC94-91-C-0002/P00296  Section  B,  Annex  A  SubCLINs  xx08AA  through 
xx08AK).  We  have  seen  other  projects  where  up-front,  volume  discounts 
resulted  in  illusory  benefits  because  the  actual  usage  was  far  less  than  planned. 


Development  Language  Cost  Impact 


National  Guard  Bureau  Comments.  The  RCAS  PMO  provided  further 
independent  productivity  information  for  PowerBuilder  to  substantiate  its 
planning  factors  of  14  to  20  FP/MM.  It  concludes  that  the  proposed  4GL 
development  environment  is  in  compliance  with  existing  policy,  no  Ada  waiver 
is  required,  the  forecasted  development  productivity  is  realistic,  and  the  funding 
is  adequate.  Therefore,  an  additional  $150  million  is  not  required. 

Evaluation  Response.  The  additional  $150  million  to  develop  the  system  using 
Ada  will  not  be  needed  because  the  use  of  the  4GL  language  has  been  approved 
by  the  ASD(C3I).  However,  selection  and  approval  of  the  4GL  created 
additional  program  risk  in  such  areas  as  maintainability,  portability,  reliability, 
reusability,  and  clarity  of  source  code.  Therefore,  we  directed 
recommendations  to  the  ASD(C3I)  to  monitor  and  periodically  assess  the  RCAS 
software  development  risk  management  with  a  view  to  identifying  and 
correcting  variances  in  a  timely  manner. 
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Other  Productivity  Risks 


National  Guard  Bureau  Comments.  The  RCAS  PMO  has  analyzed  the 
Evaluation  Report  risks  and  has  adopted  a  risk  management  plan. 

Evaluation  Response.  The  risk  management  approach  adopted  by  RCAS  is 
expected  to  provided  appropriate  oversight  of  the  development  risks. 


Underestimated  Software  Maintenance 


National  Guard  Bureau  Comments.  The  RCAS  PMO  summarized  its 
software  maintenance  planning.  It  did  not  recalculate  maintenance  costs  based 
on  the  reported  underestimate  of  $12.1  million. 

Evaluation  Response.  Based  upon  the  RCAS  planning  figures  and  the  fielding 
plan  in  the  Reserve  Component  Automation  System  Contract  Change  Proposal, 
Revision  B17,  January  1996,  the  software  maintenance  size  and  costs  were 
underestimated  by  $12.1  million.  If  GOTS  maintenance  is  excluded,  the 
underestimate  would  be  somewhat  less.  This  issue  is  not  a  language  issue.  We 
are  indicating  a  planning  calculation  error,  not  a  methodology  difference. 
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Appendix  E.  Organizations  Visited  or  Contacted 


Office  of  the  Secretary  of  Defense 

Under  Secretary  of  Defense  (Comptroller),  Washington,  DC 
Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence),  Washington,  DC 

Assistant  Secretary  of  Defense  (Reserve  Affairs),  Washington,  DC 


Department  of  the  Army 

Headquarters,  U.S.  Army  Forces  Command,  Fort  McPherson,  GA 
Chief,  National  Guard  Bureau,  Washington,  DC 
Headquarters,  National  Guard  Bureau,  Arlington,  VA 
Iowa  National  Guard  Headquarters,  Des  Moines,  IA 
Office  of  the  Chief,  Army  Reserve,  Rosslyn,  VA 
Headquarters,  U.S.  Army  Reserve  Command,  Atlanta,  GA 
99th  Regional  Support  Command,  Oakdale,  PA 
24th  Infantry  Division,  Savannah,  GA 

Reserve  Component  Automation  System,  Program  Executive  Office,  Newington,  VA 
Reserve  Component  Automation  System,  Program  Management  Office, 

Newington,  VA 


Other  Defense  Organization 

Defense  Contract  Audit  Agency,  Alexandria,  VA 


Non-Government  Organization 

The  Boeing  Company,  Vienna,  VA 
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Office  of  the  Secretary  of  Defense 

Under  Secretary  of  Defense  (Comptroller) 

Deputy  Chief  Financial  Officer 
Deputy  Comptroller  (Program/Budget) 

Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and  Intelligence) 
Assistant  Secretary  of  Defense  (Reserve  Affairs) 

Assistant  to  the  Secretary  of  Defense  (Public  Affairs) 

Director,  Defense  Logistics  Studies  Information  Exchange 


Department  of  the  Army 

Auditor  General,  Department  of  the  Army 
Chief,  National  Guard  Bureau 
Office  of  the  Chief,  Army  Reserve 

Reserve  Component  Automation  System,  Program  Executive  Office 
Reserve  Component  Automation  System,  Program  Management  Office 


Department  of  the  Navy 

Assistant  Secretary  of  the  Navy  (Financial  Management  and  Comptroller) 
Auditor  General,  Department  of  the  Navy 


Department  of  the  Air  Force 

Assistant  Secretary  of  the  Air  Force  (Financial  Management  and  Comptroller) 
Auditor  General,  Department  of  the  Air  Force 


Defense  Organizations 

Director,  Defense  Contract  Audit  Agency 
Director,  Defense  Information  Systems  Agency 
Director,  Defense  Logistics  Agency 
Director,  National  Security  Agency 

Inspector  General,  National  Security  Agency 
Inspector  General,  Defense  Intelligence  Agency 
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Non-Defense  Federal  Organizations  and  Individuals 

Office  of  Management  and  Budget 

Technical  Information  Center,  National  Security  and  International  Affairs  Division, 
General  Accounting  Office 

Chairman  and  ranking  minority  member  of  each  of  the  following  congressional 
committees  and  subcommittees 

Senate  Committee  on  Appropriations 

Senate  Subcommittee  on  Defense,  Committee  on  Appropriations 
Senate  Committee  on  Armed  Services 
Senate  Committee  on  Governmental  Affairs 
House  Committee  on  Appropriations 

House  Subcommittee  on  National  Security,  Committee  on  Appropriations 
House  Committee  on  Government  Reform  and  Oversight 
House  Subcommittee  on  National  Security,  International  Affairs,  and  Criminal 
Justice,  Committee  on  Government  Reform  and  Oversight 
House  Committee  on  National  Security 
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Part  III  -  Management  Comments 


Assistant  Secretary  of  Defense,  Command, 
Control,  Communications,  and  Intelligence 
Comments 


Final  Report 
Reference 


MEMORANDUM  FOR  DIRECTOR,  ANALYSIS,  PLANNING  AND  TECHNICAL 
SUPPORT,  OFFICE  OF  THE  INSPECTOR  GENERAL 

SUBJECT :  Draft  DoDIG  Report  -  Project  No.  6PT-5013, 

Evaluation  of  the  Reserve  Component  Automation 
System  (RCAS),  dated  May  2,  1996 


:ommenda- 
m  A.  1 . 
:hdrawn 
1  Recom- 
ldation 
l.  added. 


This  is  a  response  to  Finding  A  of  subject  report  which 
stes  the  RCAS  Program  Management  Office  (PMO)  did  not  obtain  a 
waiver  to  the  Ada  requirement.  He  disagree  with  the  DoDIG 
finding.  In  our  opinion,  RCAS  is  in  compliance  with  existing 
policy  and  does  not  require  an  Ada  waiver. 

DoD  Directive  3405.1,  dated  April  2,  1987,  makes  provisions 
for  the  use  of  advanced  software  technologies.  Section  F.2 
states  that  a  waiver  is  not  needed  'for  use  of  commercially 
available  off-the-shelf  advanced  software  technology  that  is  not 
modified  or  maintained  by  the  Department,  of  Defense . ' 

The  RCAS  PMO  has  done  an  acceptable  assessment  of 
productivity  gains,  cost  avoidance,  and  risk,  and  has  selected  a 
development  strategy  that  is  well  in  line  with  commercial  best 
practices  and  DoD  acquisition  reform. 

I 

My  response  to  the  remaining  findings  in  the  subject  report 
is  being  developed  and  will  be  provided  in  a  separate  memorandum. 

My  point-of -contact  for  this  action  is  Ms.  Connie  Leonard, 
who  is  assigned  to  the  office  of  my  Deputy  Assistant  Secretary  of 
Defense  for  Command,  Control  and  Communications,  telephone  number 
(703)  604-1489,  or  Mr.  Thomas  Bozek,  (703)  604-1592. 


Emmett  Paige,  Jr. 


Assistant  Secretary  of  Defense,  Command,  Control,  Communications,  and 

Intelligence  Comments 


OFFICE  OF  THE  ASSISTANT  SECRETARY  OF  DEFENSE 
6000  DEFENSE  PENTAGON 
WASHINGTON,  DC  20301-6000 


BfcEnjL 


COMMANO.  CONTROL. 
COMMUNICATIONS.  AND 
MTCUJOINCE 


MEMORANDUM  FOR  DIRECTOR,  ANALYSIS,  PLANNING,  AND  TECHNICAL 
SUPPORT,  OFFICE  OF  THE  INSPECTOR  GENERAL 

Subject:  Draft  DoDIG  Report  -  Project  No.  6PT-5013, 

Evaluation  of  the  Reserve  Component  Automation 
System  (RCA S) ,  dated  May  2,  1996 


The  subject  evaluation  report  has  been  carefully  reviewed. 

A  response  to  Finding  A,  dealing  with  software  acquisition  policy 
and  the  use  of  Ada,  was  provided  in  my  memorandum  of  June  16, 
1996.  The  detailed  response  to  the  remainder  of  the  report  is 
attached. 

Recent  developments  in  acquisition  policy  described  in  DoDD 
5000.1,  such  cost  as  an  independent  variable  and  integrated 
product  teams,  are  addressed  in  my  responses.  These  concepts 
recognize  that  requirements  must  be  prioritized  and  constrained 
by  available  resources  and  that  program  managers  together  with 
users  and  acquisition  officials  must  enter  into  an  agreement 
through  the  Acquisition  Program  Baseline  to  definitize  the 
performance,  cost,  and  schedule  requirements. 

The  RCAS  program  is  following  the  direction  desired  by  the 
functional  users  in,  the  Army  National  Guard  and  the  U.S.  Army 
Reserves  with  the  unqualified  support  of  the  Army  through  the 
Fiscal  Year  98-03  POM.  In  addition,  the  program  restructure 
approved  by  the  RCAS  General  Officer's  Steering  Committee  and  the 
Major  Automated  Information  System  Review  Council  in  August, 

1995,  is  on  track,  largely  based  on  improved  program  management 
and  assistance  from  OSD/Army  Integrated  Process  Teams.  I 
strongly  recommend  that  the  Assistant  Secretary  of  Defense 
(Reserve  Affairs  )  certify  the  restructured  RCAS  program  to 
Congress .  - — v 


v  ^x'jftnthoftv  M.  Valletta 
Deputy  Assistant  Secretary  of  Defense 
(C3I  Acquisition) 


cc: 

USD (C) 
ASD(RA) 
C,  NGB 
OCAR 
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OSD{C3I)  RESPONSE  TO 
DRAFT  PROPOSED  EVALUATION  REPORT 
“EVALUATION  OF  THE  RESERVE  COMPONENT  AUTOMATION  SYSTEM" 
(PROJECT  NO.  6PT-5013,  May  2, 1996) 


FINDING  A:  Data  and  Application  Software  Development 

The  RCAS  Program  Management  Office  underestimated  costs  and  planned  insufficient 
funding  for  the  data  and  applications  software  development  by  about  $160  million.  The 
PMO  did  not  obtain  a  waiver  to  the  Ada  requirement,  significantly  overestimated  the 
software  development  productivity,  and  underestimated  the  maintenance  portion.  As  a 
result  of  the  insufficient  funding,  the  software  development  in  the  required  language  will 
cause  schedule  slips  and  the  Army  National  Guard  and  the  Army  Reserve  requirements 
not  being  fully  met. 

IG  Recommendations  for  Corrective  Action  for  Finding  A: 

Chief,  National  Guard  Bureau  should:  (1)  Cease  further  data  and  applications 
development  until  Ada  is  selected  as  required  by  DoDD  3405.1  before  the  project  is 
overcommitted  to  a  fourth-generation  language.  (2)  Reestimate  the  cost  and  schedule  of 
the  project  based  on  realistic  development  productivity  and  maintenance  sizing,  or 
rescope  the  Data  and  Applications  functions  to  fit  the  available  cost  and  schedule. 

(3)  Require  full  justification,  including  a  life-cyclc  cost  analysis  and  a  risk  analysis  that 
addresses  technical  performance  and  schedule  impact,  if  an  Ada  waiver  is  proposed. 

(4)  Cease  the  more  than  $2  million  procurement  of  Structured  Query  Language  server  and 
fourth-generation  language  products  planned  for  FY  1996,  unless  an  Ada  waiver  is 
granted  and  pilot  applications  are  successfully  completed. 

OSD(C3I)  Response:  Non-concur.  ASD(C3I)  memorandum  of  June  14,  1996,  provided 
the  response  to  this  finding.  A  copy  of  the  memorandum  is  attached.  Additionally, 
through  the  Major  Automated  Information  System  Review  Council  (MAISRC)  oversight 
process  prescribed  by  DoD  Directive  (DoDD)  5000. 1  of  March  15, 1996,  the  RCAS 
program  is  closely  monitored.  As  the  MAISRC  Chairman,  ASD(C3I)  will  ensure  that  any 
custom  software  development  required  is  accomplished  in  accordance  with  policy 
prescribed  by  DoDD  3405. 1 . 

FINDING  B:  Telecommunications  Requirements  and  Funding 
The  Chief,  National  Guard  Bureau,  neither  identified  specific  telecommunications 
requirements  for  equipment  and  services  nor  determined  total  telecommunications  cost 
for  the  RCAS  Program.  The  RCAS  PMO  did  not  complete  and  validate  requirements  for 
telecommunications  equipment  and  services.  Further,  the  RCAS  PMO  did  not  prepare 
site  surveys  to  identify  and  validate  the  cost  of  preparing  each  site  for  the  installation  of 
telecommunications  equipment  and  services.  As  a  result,  the  RCAS  PMO  has  not 
completed  a  documented,  validated,  and  comprehensive  telecommunications 
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management  plan  to  obtain  the  most  cost-effective  telecommunications  circuit 
configuration  and  is  unable  to  determine  the  total  cost  of  the  telecommunications  portion 
of  the  RCAS  Program.  Therefore,  the  total  cost  of  RCAS  communications  is  probably 
underestimated  and  the  program  is  probably  underfunded. 

IG  Recommendations  for  Corrective  Action  for  Finding  B: 

Chief,  National  Guard  Bureau  ensure  that  prior  to  any  further  procurement  of 
telecommunications  equipment  and  services  for  RCAS,  the  following  actions  are 
completed:  (a)  Determine  baseline  of  existing  telecommunications  equipment  and 
services,  and  validate  requirements  for  the  baseline  of  existing  telecommunications 
equipment  and  services,  (b)  Identify  the  number  of  subscribers;  determine  proposed  user 
requirements  for  future  telecommunications  equipment  and  services  for  each  site;  assess 
the  validity  of  proposed  user  requirements;  and  complete  a  documented,  validated,  and 
comprehensive  telecommunications  configuration  management  plan  based  on  validated 
proposed  user  requirements,  (c)  Determine  the  total  cost  of  the  telecommunications 
equipment  and  services  portion  of  the  RCAS  program;  (d)  Project  budgetary  costs  for  the 
telecommunications  equipment  and  services  portion  of  the  RCAS  program  and  establish  a 
funding  program  for  the  Army  Reserve  and  National  Guard. 

OSD(C3I)  Response:  Partially  concur.  Prior  to  MAISRC  approval  for  deployment,  an 
RCAS  Telecommunications  Plan  must  be  approved  by  this  office.  Defense  Information 
Systems  Agency  (DISA)  is  responsible  for  validating  the  proposed  telecommunications 
architecture  and  ensuring  compliance  with  DoD  telecommunications  policies,  including 
consistency  and  conformance  with  the  Defense  Information  Systems  Network,  transition 
to  the  Defense  Messaging  System,  and  conformance  with  the  DoD  Technical  Architecture 
for  Information  Management  To  obtain  approval  by  this  office,  the  Telecommunications 
Plan  must  include  a  description  of  the  functional  telecommunications  requirements, 
definition  of  responsibilities  for  all  parties  involved  in  managing  and  operating  the 
network,  detailed  network  description  and  all  interfaces,  and  traffic  workload 
characteristics.  It  is  recognized  that  at  the  time  of  your  audit,  the  draft 
telecommunications  plan  lacked  some  of  the  substantive  details  required  in  these  areas. 
An  updated  Telecommunications  Han  has  been  drafted,  with  guidance  and  assistance 
from  DISA  and  was  provided  to  all  Working-Level  Integrated  Product  Team  (WIPT) 
members  for  review  on  July  3, 1996.  In  addition,  MG  Kelley,  Vice  Director  DISA  was 
briefed  on  the  RCAS  telecommunications  plan  on  June  21, 1996,  and  concurs  that  RCAS 
is  moving  in  the  proper  direction  for  compliance  with  DISA  plans  and  architecture.  The 
Telecommunications  Plan  will  be  reviewed  and  approved  prior  to  MAISRC  approval  for 
deployment. 

Nonconcur  with  recommendations  requiring  total  site  surveys  in  advance  of  program 
initiation  and  establishment  of  a  full  funding  program  prior  to  commencement  of  the 
program.  Total  site  surveys  are  cost  prohibitive  and  often  become  outdated  quickly. 
Moreover,  the  RCAS  PMO  has  more  definitive  information  on  its  sites  than  most 
programs  because  of  the  old  installed  base  in  existence  at  approximately  821  sites  out  of  a 
total  universe  of  approximately  4,000  sites.  With  regard  to  the  cost  of  the 
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telecommunications  for  RCAS,  the  program  is  following  guidance  contained  in  DoDD 
5000.1  for  Cost  as  an  Independent  Variable  (CATV).  Under  this  concept,  acquisition 
managers  establish  realistic  objectives  for  programs  and  follow  through  by  trading  off 
performance  and  schedule  to  achieve  a  balanced  set  of  goals.  The  MAISRC  Cost  WIPT 
will  evaluate  costs  and  planned  actions  to  validate  that  baselined  requirements  can  be  met 
prior  to  approval  for  deployment  Additionally,  the  Army  National  Guard  (ARNG)  and 
the  U.S.  Army  Reserves  (USAR)  have  agreed  on  the  revised  Telecommunications  Plan 
and  the  prioritization  of  requirements.  Further,  RCAS  will  use,  with  DISA  approval, 
excess  capacity  on  other  networks  provisioned  by  the  ARNG  and  the  USAR. 

FINDING  C:  Commercial  Off-the  Shelf  Infrastructure  Budget  Risks 
Budgeted  funds  to  purchase  the  RCAS  COTS  infrastructure  (personal  computers,  office 
automation  software,  and  telecommunications)  are  at  risk  from  other  areas  of  die  program 
that  are  underbudgeted.  The  RCAS  program  has  year  to  year  imbalances  of  Other 
Procurement  Army  funds  needed  to  finance  the  Boeing  contract  Additionally,  as  stated 
in  Findings  A  and  B,  the  RCAS  PMO  has  underestimated  software  development  and  has 
not  determined  telecommunications  costs.  Insufficient  infrastructure  investment  could 
result  in  the  Army  National  Guard  and  Army  Reserve  units  being  forced  to  wait  more 
than  six  years  for  the  anticipated  benefits  from  deploying  the  RCAS  commercial  off-the- 
shelf  infrastructure. 

IG  Recommendations  for  Corrective  Action  for  Finding  C: 

Chief,  National  Guard  Bureau  should:  (1)  Formally  baseline  the  RCAS  commercial  off- 
the-shelf  hardware  and  software  infrastructure  delivery  schedule  and  quantities. 

(2)  Ensure  that  multiple  use  of  existing  computer  systems  is  considered  to  further  support 
the  Reserve  Component  users. 

OSD(C3I)  Response:  Concur.  The  Army  POM  submitted  to  OSD  has  adjusted  the 
funding  to  align  with  the  current  program  requirements.  DoD  5000.2-R  requires  approval 
of  the  APB  for  each  major  AIS  by  the  Milestone  Decision  Authority,  ASD(C3I).  On  June 
28, 1996,  a  second  draft  of  the  APB  incorporating  all  comments  of  the  members  of  the 
RCAS  Programmatic  WIPT  was  circulated  to  the  WIPT  members.  Following  inclusion 
of  final  comments,  the  APB  will  be  staffed  for  MDA  approval.  In  addition,  the  removal 
of  restrictive  Congressional  language  has  provided  a  capability  for  use  of  existing 
computer  resources  in  RCAS.  The  new  RCAS  architecture  is  compliant  with  the  Defense 
Information  Infrastructure  Common  Operating  Environment  This  will  allow  additional 
resources  to  be  interconnected  with  equipment  currently  owned  or  acquired  in  the  future 
by  RCAS  users. 

Conclusion:  OSD(C3I)  supports  the  RCAS  restructure  decision  presented  to  the 
MAISRC,  initially  in  August  1995,  and  at  the  status  briefing  on  April  15, 1996.  The 
MAISRC  staff  is  co-c hairing,  with  the  RCAS  Program  Manager,  activities  associated 
with  preparing  for  the  deployment  of  the  RCAS  infrastructure.  All  Army  and  OSD 
functional  and  technical  principals,  including  the  Office  of  the  Assistant  Secretary  of 
Defense  (Reserve  Affairs)  are  involved  in  the  efforts  necessary  to  plan  for  the  program 
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proposed  by  the  Chief,  National  Guard  Bureau.  Upon  completion  of  the  proposed 
program  plans,  including  the  APB,  and  successful  operational  testing  of  the  proposed 
system,  ASD(C3I)  will  support  the  infrastructure  fielding  decision  proposed  by  the  Chief, 
National  Guard  Bureau  and  the  RCAS  General  Officer's  Steering  Committee. 

Recommendation:  That  the  Assistant  Secretary  of  Defense  (Reserve  Affairs)  certify  to 
Congress  that  RCAS  is  technically  feasible,  adequately  funded,  executable,  and  will  meet 
the  Army's  National  Guard  and  Reserve  requirements.  With  the  re-establishment  of  the 
RCAS  General  Officer's  Steering  Committee  by  the  Chief,  National  Guard  Bureau,  the 
commitment  of  the  Army  to  the  RCAS  program  through  its  funding  of  the  restructured 
RCAS  program  and  the  cooperation  between  the  ARNG  and  the  USAR  user 
communities,  make  the  RCAS  program  more  viable  than  ever  before. 
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DEPARTMENTS  OF  THE  ARMY  AND  THE  AIR  FORCE 
NATIONAL  GUAM  BUREAU 
2500  ARMY  PENTAGON 
WASHINGTON,  D.C.  20510-2500 


NGB-IR-C  (36-2b) 

MEMORANDA  THRU 
Director  of  the 


27  June  1996 


Command  and  Control  Computer  and 


Director,  Information  S' 
Communicatioi 


ProgranT'Director,  Policy.  Followup  and  Training  (SAAG-PMF-I 

FOR  The  Inspector  General,  Department  of  Defense  (Auditing) 

SUBJECT:  Evaluation  of  the  Resen/e  Component  Automation  System,  (Project 
No.  6PT-5013) 


1.,  Reference  SAAG-PRF-E  Memorandum,  dated  15  May  1996,  SAB 

2.  Per  your  request,  the  Audit  Report  has  been  reviewed  and  the  response  is 
enclosed. 

The  National  Guard  Bureau  points  of  contact  are  Mr.  Lane  G.  Haskew,  703-681- 
5989  or  Mrs.  Patricia  A.  Gallop,  703-681-4604,  NGB-IR-C. 

FOR  THE  CHIEF.  NATIONAL  GUARD  BUREAU: 


Enel 

as 


^  JOHN  H.  TATE  O 

Acting  Director,  Internal  Review  and 
Audit  Compliance 


National  Guard  Bureau  Comments 


DEPARTMENTS  OF  THE  ARMY  AND  THE  AIR  FORCE 

NATIONAL  GUARD  BUREAU 
WASHINGTON,  D.  C.  20310-2600 


NGB-RCS-RA 


25  JUN  1996 


MEMORANDUM  FOR  DEPARTMENT  OF  DEFENSE  INSPECTOR  GENERAL, 

400  ARMY  NAVY  DRIVE  (ROOM  801), 

ARLINGTON,  VA  22202-2884 

SUBJECT:  Evaluation  of  Reserve  Component  Automation  System  (RCAS)  Report  —  Project 
No.  6PT-5013,  Prepared  by  the  Department  of  Defense  Inspector  General  (DOD  IG), 

May  2, 1996 


1.  I  have  reviewed  the  DOD  IG  evaluation  of  the  RCAS  and  concur  with  the  actions  taken  by 
the  Program  Management  Office  (PMO).  Based  on  this  review,  I  find  that  RCAS  is  technically 
feasible,  adequately  funded,  executable,  and  will  meet  the  Army's  National  Guard  and  Reserve 
requirements  for  an  Automated  Information  System  (AIS)  to  support  unit  administration  and 
mobilization  needs  at  all  echelons  of  command  well  into  the  21st  century.  Therefore,  I  see  no 
justification  to  cease  data  and  applications  development  or  the  procurement  of 
telecommunications  equipment  and  services. 

2.  An  Executive  Summary  highlighting  the  actions  taken  by  the  RCAS  PMO  and  a  detailed 
response  to  the  DOD  IG  findings  is  attached.  The  DOD  IG  findings  were  appropriately 
addressed.  I  know  of  no  significant  findings  that  should  preclude  this  program  from  being 
certified  to  Congress. 

3.  The  Acquisition  Program  Baseline  will  be  presented  for  approval  at  the  Major  Automated 
Information  System  (MAISRC)  Milestone  III  decision  briefing  (subject:  Permission  to  field  the 
RCAS  infrastructure)  scheduled  for  late  in  the  fourth  quarter  of  FY96.  The  PMO  is  utilizing  the 
DODD  5000.1/DODR  5000.2-R  Integrated  Process  Team  (IPT)  approach  to  obtain  approval 
and  buy-in  from  the  appropriate  DOD  and  U.S.  Army  approving  agencies.  To  date,  this  process 
is  on  track  to  be  successfully  concluded  at  the  MAISRC  Milestone  III  decision.  The  IPTs, 
coupled  with  the  RCAS  General  Officer  Steering  Committee's  direct  oversight  of  the  program, 
will  enable  me  to  ensure  that  the  program  remains  within  budget  and  schedule  baselines,  and 
will  provide  the  Guard  and  Reserve  users  with  an  operationally  effective,  suitable  and 
affordable  AIS. 

- 

Atch  EDWARD  D,  BACA 

LTG,  USA 

Chief,  National  Guard  Bureau 
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Response  to  the 

Evaluation  of  the  Reserve  Component  Automation  System 
Prepared  by  the  Office  of  the  Inspector  General 
Department  of  Defense 

Project  No.  6PT-5013 
May  2, 1996 


EXECUTIVE  SUMMARY 

OVERVIEW.  The  Assistant  Secretary  of  Defense  for  Reserve  Affairs,  (ASD(RA))  acting  upon 
congressional  direction,  requested  the  Office  of  the  Inspector  General,  Department  of  Defense 
(DOD IG) ,  conduct  a  technical  evaluation  of  the  RCAS  Program  to  determine  if  it  was  adequately 
funded,  executable,  and  would  meet  the  Army’s  National  Guard  and  Reserve  requirements.  The 
evaluation  report  identified  three  major  findings  in  software,  telecommunications,  and  budgeting, 
each  of  which  pose  potentially  significant  risk  to  the  Program.  This  paper  is  a  response  to  those 
findings. 

DISCUSSION. 

Finding  A. 

Summary  of  Finding  —  The  IG  stated  that  the  costs  of  Data  and  Application  Software 
Development  were  underestimated  by  S160M  since  the  Program  Management  Office  (PMO)  based 
productivity  assumptions  on  using  a  commercial  off-the-shelf  (COTS)  product  (PowerBuilder) 
rather  than  Ada.  The  IG’s  assertion  was  that  the  PMO  needed  to  obtain  a 
program-wide  waiver  for  not  using  Ada. 

Response  —  RCAS  is  in  full  compliance  with  the  DOD  Ada  policy  which  treats  advanced 
software  technologies  (ASTs)  as  COTS  with  preference  over  Ada.  Mr.  Paige,  Assistant  Secretary 
of  Defense  for  Command,  Control,  Communications  and  Intelligence  (C3I),  reviewed  DOD  IG 
Finding  A  and  has  concurred  in  writing  with  the  program’s  approach.  Additionally,  based  on  the 
IG  report,  the  PMO  has  earmarked  $10  million  to  be  used  for  Ada  development  when  required. 


Finding  B. 

Summary  of  Finding  —  The  IG  could  not  verify  the  total  telecommunications  costs  for  RCAS 
because  specific  telecommunications  requirements  were  not  identified,  site  surveys  had  not  been 
conducted,  and  the  telecommunications  management  plan  had  not  been  completed. 

Response  —  While  these  findings  were  partially  accurate  at  the  time,  the  Telecommunications 
plan  has  been  rewritten  with  the  participation  of  Information  Systems  Engineering  Command 
(ISEC),  Army  National  Guard  (ARNG)  and  the  U.  S.  Army  Reserve  (USAR),  and  is  being  staffed 
to  gain  the  concurrence  of  the  Defense  Information  Systems  Agency  (DISA),  ISEC,  Office  of  the 
Secretary  of  Defense  (OSD)  C3I,  and  die  Office  of  the  Director  of  Information  Systems  for 
Command,  Control,  Communications  and  Computers  (DISC4).  The  fully  staffed  plan  will  be 
completed  and  presented  at  the  Major  Automated  Information  System  Review  Council  (MAISRC) 
Milestone  III  decision  briefing  in  4th  Quarter  FY96.  Specific  telecommunications  requirements 
are  defined  in  this  plan.  They  were  determined  using  an  accepted  business  practice  of  modeling 


National  Guard  Bureau  Comments 


the  telecommunications  requirements  based  on  empirical  and  actual  data  collected  from  RCAS 
customers.  The  ARNG  and  USAR,  who  are  responsible  for  all  circuit  provisioning,  will  capitalize 
on  existing  circuits  and  incorporate  RCAS  requirements  into  their  future  telecommunications 
plans.  The  RCAS  technical  architecture  solution  is  robust  and  flexible  enough  to  evolve  with  the 
changing  telecommunications  topology  without  causing  added  risk  to  the  system  operation. 

Finding  C. 

Summary  of  Finding  -  The  IG  Report  suggested  that  funds  to  purchase  COTS  infrastructure  were 
at  risk  due  to  possible  funding  shortfalls  from  Findings  A  and  B,  as  well  as  from  year-to-year 
imbalances  in  OPA  funds. 

Response  —  The  issues  addressed  in  Finding  A  and  B  do  not  present  a  current  budget  shortfall  to 
the  program.  The  recently  completed  FY98-03  Army  Program  Objective  Memorandum  (POM) 
corrected  the  funding  profile  to  align  with  the  current  contract  requirements.  The  ARNG  and 
USAR  have  both  POMed  for  the  appropriate  Operations  and  Maintenance  (O&M)  funds  in  the  out 
years  to  cover  operating  costs  not  previously  addressed.  The  fielding  approach  requires  seven 
years  because  of  the  funding  profile.  The  PMO  has  been  working  with  die  ARNG  and  USAR  to 
modify  the  fielding  strategy  within  the  seven  years  to  touch  as  many  users  as  possible  as  early  as 
possible. 

CONCLUSION.  The  DOD  IG  recommended  that  LTG  Baca,  Chief,  National  Guard  Bureau, 
(CNGB)  cease  software  development  efforts  and  telecommunications  procurement  until  their 
findings  are  resolved.  In  light  of  the  above  response  to  the  DOD  IG  findings,  that  action  is  not 
necessary.  The  RCAS  PMO  continues  to  refine  the  Acquisition  Program  Baseline  in  preparation 
for  an  OSD  MAISRC  Milestone  III  decision  to  field  the  infrastructure.  Additionally,  the  PMO 
continuously  addresses  and  resolves  any  issues  raised  as  a  matter  of  normal  practice  through  the 
Integrated  Product  and  Process  Development  (IPPD)  concept  of  using  Integrated  Process  Teams 
(IPT)  throughout  the  acquisition.  The  use  of  IPTs,  as  well  as  oversight  by  the  Program  Executive 
Office  (PEO),  CNGB,  and  the  RCAS  General  Officer  Steering  Committee  (GOSC)  will  continue 
after  the  MAISRC.  To  date,  all  required  program  plans  arc  on  schedule  and  the  program  is 
executable.  The  DOD  IG  findings  were  appropriately  addressed;  consequently,  there  are  no 
significant  technical  or  funding  issues  that  should  preclude  this  program  from  being  certified  to 
Congress. 

RECOMMENDATION.  Ms.  Lee  certify  to  Congress  that  RCAS  is  technically  feasible, 
adequately  funded,  executable,  and  will  meet  the  Army’s  National  Guard  and  Reserve 
requirements  well  into  the  future. 
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DETAILED  RESPONSE 


Introduction 

The  Assistant  Secretary  of  Defense  for  Resen/e  Affairs,  acting  upon  congressional 
direction,  requested  the  Office  of  the  Department  of  Defense  Inspector  General  (DOD 
IG),  conduct  a  technical  evaluation  of  the  RCAS  Program  to  determine  if  it  was 
adequately  funded,  executable,  and  would  meet  the  Army’s  National  Guard  and  Reserve 
requirements  for  an  Automated  Infomation  System  to  support  unit  administration  and 
mobilization  needs  at  all  echelons  of  command.  The  DOD  IG,  from  October  1995  through 
April  1996,  conducted  their  technical  evaluation  of  the  RCAS  Program.  The  DOD  IG 
Evaluation  Report,  with  enclosures,  summarized  the  results  of  the  technical  assessment 
and  identified  three  potentially  significant  risks  to  successful  RCAS  Program  execution. 
These  risks  concern  data  and  application  software  development,  telecommunication 
requirements  and  funding,  and  commercial  off-the-shelf  (COTS)  infrastructure  budget 
risks.  In  light  of  these  risks,  the  DOD  IG  recommends  the  Program  cease  further  data 
and  applications  development  efforts,  cease  procurement  of  RCAS  telecommunication 
equipment  and  services,  and  establish  a  formal  baseline  for  the  delivery  schedule  and 
quantities  of  commercial  off-the-shelf  infrastructure. 

In  the  remainder  of  this  report,  excerpts  of  the  DOD  IG  Evaluation  Report  are  provided  in 
italics  along  with  a  response  which  addresses  the  concerns  of  the  DOD  IG. 

Response  to  Findings 

Finding  A.  Data  and  Application  Software  Development 

The  RCAS  Program  Management  Office  underestimated  costs  and  planned  Insufficient 
funding  for  the  data  and  applications  software  development  by  about  $160  million.  The 
PMO  did  not  obtain  a  waiver  to  the  Ada  requirement,  significantly  overestimated  the 
software  development  productivity,  and  underestimated  the  maintenance  portion.  As  a 
result  of  the  insufficient  funding,  the  software  development  in  the  required  language  will 
cause  schedule  slips  and  the  Army  National  Guard  and  the  Army  Reserve  requirements 
not  being  fully  met. 

Non-Concur.  The  basis  for  Finding  A  rests  solely  on  the  premise  that  PMO  RCAS  did 
not  obtain  an  Ada  waiver,  and  therefore  significantly  overestimated  software 
development  productivity.  This  finding  is  moot  in  light  of  the  following  excerpts  from  the 
OSD/C3I  Memorandum  (attached  TAB  1). 

“In  our  opinion,  RCAS  does  not  require  an  Ada  waiver  because  it  is  in 
compliance  with  existing  policy.' 

“The  RCAS  PMO  has  done  an  acceptable  assessment  of  productivity 
gains,  cost  avoidance,  and  risk,  and  has  selected  a  development  strategy 
that  is  well  in  line  with  commercial  best  practices  and  DOD  acquisition 
reform." 
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Software  Development  Approach 

...  The  funding  allocated  to  the  Data  and  Applications  software  development  time  and 
materials  portion  of  the  contract  was  not  sufficient  for  an  Ada  development  approach. 
Therefore,  the  Validation  Assessment  Team  selected  a  fourth-generation  language 
approach  based  on  its  efficiency. 

PMO  RCAS  has  applied  a  managed  risk  approach  to  software  development.  This 
approach  exploits  both  Government  and  commercial  off-the-shelf  products,  applying 
advanced  4GL  tools  in  a  rapid  prototyping  environment  with  extensive  user  participation 
in  small  timebox  increments  to  maintain  control  over  software  development.  In  addition, 
the  PMO  has  established  metrics  and  risk  management  programs  to  identify  and 
address  potential  problems  before  they  become  critical  Program  issues. 

Development  Language  Issues 

...the  RCAS  use  of  a  COTS  code  generator  will  requim  coding  and  maintenance  at  the 
generated  code  level.  Because  the  PMO  will  develop  and  maintain  software  at  the 
generated  code  level,  DOD  policy  requires  an  Ada  waiver... 

DOD  Directive  3405.1,  ‘Computer  Programming  Language  Policy,"  2  APR  87  prefers, 
based  on  an  analysis  of  the  life-cycle  costs  and  impact,  the  use  of  off-the-shelf 
application  packages  and  advance  software  technology.  Further,  a  waiver  need  not  be 
obtained  for  the  use  of  commercially  available  off-the-shelf  applications  software  or 
advanced  software  technology  that  is  not  modified  or  maintained  by  DOD.  “Code” 
generated  by  these  instances  will  be  maintained  by  the  tool  only.  RCAS  software 
development  strategy  does  not  include  modification  of  the  tool  set  or  Its  output  by 
anything  other  than  the  tool  set  Therefore  these  technologies  are  maintained  by  the 
vendor  and  not  subject  to  the  waiver  consideration.  Mr.  Paige,  ASD  (C3I)  has  reviewed 
the  program  strategy  and  agrees. 

The  selected  4GL  is  pmdicated  on  the  idea  that  the  developer  would  modify  the 
generated  code  to  customize  the  user  interface,  processing,  and  application  interfaces. 
The  selected  4GL  includes  tools  to  facilitate  such  code  level  changes...  Even  if  Ada 
was  used  whenever  changes  were  needed  to  the  selected  4GL  applications,  generated 
or  C  code  changes  would  be  necessary  to  transfer  control  and  data  between  the 
languages.  Therefore,  without  a  waiver  the  regulations  require  RCAS  to  use  Ada. 

The  selected  4GL  is  predicated  on  the  idea  that  the  developer  will  employ  the  tool  alone 
to  customize  the  user  interface,  processing,  and  application  interfaces.  Code  level 
modifications  are  not  involved.  Cases  that  might  require  code  level  changes  are 
facilitated  by  tools  included  in  the  4GL  package.  These  artifacts  are  simply  “scripts’ 
comparable  to  Microsoft  Excel  macros  that  define  formulas,  labels  or  constants  within 
the  spreadsheet. 

PowerBuilder  5.0  from  PowerSoft  is  a  central  component  of  the  RCAS  software 
engineering  environment.  PowerBuilder  5.0  differs  from  classic  code  generators  in  that 
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it  does  not  generate  code  which  is  then  modified  by  the  developer  to  make  the 
generated  code  functional.  Rather,  it  produces  executable  code  (components)  for 
generic  windows  services,  etc.  that  may  be  used  in  conjunction  with  Powerscript  (a 
scripting  language  internal  to  the  PowerBuilder  5.0  development  environment). 
PowerBuilder  generates  object  code  for  execution  of  the  designed  windows,  and 
provides  the  developer  with  'events'  and  user  functions  which  can  be  scripted  by  the 
programmer. 

C  code  changes  are  NOT  necessary  to  transfer  control  and  data  between  languages. 
PowerBuilder  5.0  can  directly  access  Ada  components  without  a  C  language  interface. 

None  of  the  examples  cited  in  the  Evaluation  Report  require  coding  external  to  the 
PowerBuilder  5.0  development  environment.  The  following  bullets  identify  specifically 
how  the  examples  listed  could  be  implemented  using  the  PowerBuilder  5.0 
development  environment. 

-  Disabling  a  keystroke  in  a  data  window  —  can  be  implemented  in  an  event  script 
using  key  down  function;  can  be  set  up  when  establishing  a  data  window  by 
setting  the  tab  order;  the  mouse  can  be  deactivated;  the  data  window  can  be  set 
read  only. 

-  Implementing  cut,  copy,  and  paste  in  the  "Edit"  menu  -  can  be  implemented  on 
the  menu,  using  common  window  functions. 

-  Scrolling  row  by  row  instead  of  scrolling  by  page  or  by  group  -  can  be 
implemented  with  a  single  line  of  script;  scroll  by  row  is  default  scrolling. 

-  Using  sh'rft-FI  for  help.  -  Shift-FI  is  context  sensitive  help  -  topic  is  passed  to 
help  application;  can  be  accomplished  in  a  script  with  standard  PowerBuilder 
functions;  get  focus;  get  object  at  pointer  (in  a  data  window). 

-  Determining  the  last  item  clicked  on  a  multi-select  listbox  -  can  be  implemented 
using  standard  PowerBuilder  functions  which  perform  normal  search  until  find 
last;  search  at  current  item  for  lists;  search  at  next  item  for  data  window. 

-  Passing  Windows  messages  into  an  application  -  can  pass  windows  messages 
using  Windows  Software  Development  Kit  for  NT  or  Resource  Kit  for  NT. 

-  Providing  text  search  in  a  drop  down  data  window  -  can  be  implemented  using 
standard  PowerBuilder  functions  which  perform  text  search  returning  the  row; 
use  data  window  with  child  window  as  the  drop  down  list  box,  then  perform  find. 

-  Conditionally  preventing  user  input  into  columns  -  can  be  implemented  using 
standard  PowerBuilder  functions  which  use  Item  Changed  event,  check  values, 
or  make  some  data  windows  read-only  on  certain  conditions. 
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-  Updating  multiple  database  tables  from  the  same  data  window  —  can  use 
shared  data  windows  to  accomplish  this  update. 

-  Reading  a  file  larger  than  32,766  bytes.  Current  limit  is  64K  bytes.  If  larger  size 
is  needed,  a  database  blob  type  can  be  used.  The  real  limit  is  the  memory  on  the 
PC. 

-  Sending  data  from  an  application  via  e-mail.  There  are  MAPI  functions  available 
to  pass  data  via  mail. 

-  Determining  if  a  windows  application  is  running  in  Windows  NT.  Windows  NT 
functions  can  be  called  directly  to  determine  whether  an  application  is  running. 

The  RCAS  Validation  Assessment  Team  (VAT)  estimated  that  approximately  5%  of 
RCAS  functionality  may  be  developed  using  Ada.  The  PMO  has  set  aside  $10  million 
to  support  this  functionality  development.  To  support  the  PMO  in  identifying  the 
approximate  cost  of  this  development  Boeing  utilized  the  same  model  used  to  build  the 
estimate  in  support  of  the  restructure.  This  will  allow  the  PMO  to  plan  for  and  monitor 
the  cost  of  any  Ada  development. 

If  the  PMO  pursues  an  Ada  waiver,  the  Justification  should  include  how  the  PMO  will 
abate  the  additional  risks  of  4GL  development.  These  4GL  development  risks  include 
the  following: 

-  The  RCAS  applications  may  be  too  large  for  the  code  generator.  Fourth- 
generation  languages  have  been  used  extensively  for  prototyping  and  ad  hoc 
application  development.  There  is  a  risk  that  the  large  RCAS  applications  will 
cause  overflows  of  internal  tables  and  memory  exceptions  in  the  code  generator. 

RCAS  Is  not  being  developed  as  one  single  executable  icon  but  rather  as  a  series  of 
integrated  applications.  The  applications  design  accounts  for  performance  and 
capacity  issues  to  specifically  preclude  table  overflows  and  memory  exceptions. 
PowerBuilder  5.0  has  removed  or  greatly  reduced  the  dependency  on  internal  tables. 
Furthermore,  we  have  constructed  sample  PowerBuilder  4.0  and  5.0  applications  which 
are  similar  in  size  and  complexity  to  a  typical  RCAS  timebox  and  experienced  no  such 
problems  to  date. 

The  strategy  employs  an  ‘N-Tiered’  application  architecture.  The  Graphical  User 
Interface  is  not  directly  tied  to  the  database.  This  layered  structure  involves  the  use  of 
brokered  services  that  provide  flexibility  in  locating  the  business  logic  layer  at  the  server 
or  client.  This  aspect  increases  reuse  and  decreases  maintenance  due  to  modularized, 
object-oriented  components.  Fielded  applications  will  have  a  layer  of  abstraction  that 
will  isolate  change  traffic  overtime. 
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-  The  applications  will  run  too  slowly  and  take  too  much  memory.  Fourth- 
generation  languages  automatically  include  application  domain  services  that  may 
or  may  not  be  used  by  the  application.  The  RCAS  contract  specifies  an 
interpretive  4GL.  There  is  considerable  risk  that  RCAS  users  will  not  accept  the 
application  start-up  delays  and  response  times.  There  is  some  risk  that  the 
applications  will  use  too  much  disk  space  and  that  useful  sets  of  applications 
cannot  be  loaded  at  the  same  time. 

PowerSoft  has  implemented  native  code  generation  built  on  compiler  technology.  This 
enhancement  improves  application  performance  in  key  areas  such  as  script  execution, 
mathematical  expressions,  function  calls  and  array  processing. 

Windows  NT  and  code  generator  changes  may  cause  additional  application 
changes.  Frequent  changes  in  Windows  NT  and  the  code  generator  can  be 
expected  until  the  market  place  matures.  There  is  a  risk  that  these  changes  will 
cause  additional  application  updates,  testing,  and  redelivering.  Application 
changes  would  cause  support  cost  increases,  delivery  and  reinstallation  costs, 
and  passible  configuration  variety  in  the  field. 

Historically  COTS  upgrades  of  Windows-based  products  have  provided  compatibility 
with  previous  versions.  We  see  no  reason  for  this  to  change.  In  fact,  products  such  as 
PowerBuilder  5.0,  that  are  compliant  with  Windows  standards  and  Object  Linking  and 
Embedding  (OLE)  architecture,  will  be  less  likely  to  cause  coding  changes  than  non- 
compliant  3GL  languages.  In  addition,  PowerBuilder  5.0  provides  the  capability  of 
porting  applications  developed  in  Windows  NT  to  other  platforms  (e.g.  Windows  3.1 , 
Windows  95,  UNIX)  without  any  modifications. 

-  Development  and  support  tools  for  the  code  generator  are  inadequate. 

Production  sizing,  productivity,  complexity  measurement,  execution  tracing,  and 
test  case  capture/replay  tools  may  not  be  available.  There  is  a  risk  that  the  code 
responsible  for  execution  problems  will  not  be  identified.  The  development  at  the 
code  generator  and  generated  code  levels  means  that  the  testing  and  support 
must  also  be  at  multiple  levels.  There  Is  a  risk  that  the  lower  level  changes  will 
be  forgotten  or  not  changed  to  match  the  higher  level  changes.  There  is  a  risk 
that  test  tools  will  not  be  available  to  test  generated  code  changes. 

We  have  selected  development  and  support  tools  that  more  than  adequately  support 
PowerBuilder  life  cycle  development.  These  include  Rational  ROSE  CASE  tool,  which 
provides  round  trip  engineering  capabilities  for  Ada,  PowerBuilder,  and  C++  for  UNIX 
and  Windows  NT  environments;  SQA  Team  Test  tool,  which  provides  the  ability  to 
capture  and  replay  test  cases  for  PowerBuilder  applications,  and  automatically  creates 
test  cases  from  PowerBuilder.  Additionally,  numerous  support  tools  are  available  at  the 
Internet  Web  Site. 
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-  The  RCAS  applications  may  become  unsupportable.  The  selected  code 

generator  uses  a  proprietary  nonstandard  language  with  no  alternative  source  or 
translators.  There  are  currently  about  two  dozen  4GL  products  competing  for  top 
places  in  productivity,  power,  graphical  user  interface,  and  rapid  application 
development  project  support.  There  is  a  risk  that  the  selected  4GL  will  become 
obsolete  or  that  other  4GLs  will  dominate.  There  is  a  risk  that  the  developed 
applications  would  become  unsupportable  and  that  they  would  have  to  be 
replaced. 

There  is  no  reason  to  believe  that  PowerBuilder  will  become  obsolete,  and  the  trend 
within  DOD  appears  to  be  in  the  opposite  direction.  PowerBuilder  has  a  40%  market 
share  in  client  server  application  development  tools  (Century  Market  Research,  Fall  95). 
PowerSoft’s  parent  company  Sybase  reported  1995  revenues  of  $957  million.  Sybase 
is  the  sixth  largest  independent  software  company  in  the  world.  PowerBuilder’s 
strength  is  that  it  does  not  require  any  language  compiler.  In  the  event  that  we  decide 
to  reengineer  PowerBuilder  5.0  objects  into  Ada  or  C++  we  would  accomplish  this  using 
Rational  ROSE  round  trip  engineering  capabilities. 

In  addition  to  the  regulatory  and  risk  issues  presented  above,  the  RCAS  PMO  has  not 
demonstrated  that  the  selected  4GL  has  the  flexibility  and  performance  needed  for 
RCAS  by  successfully  completing  the  pilot  applications.  In  fact,  the  RCAS  PMO  has 
not  demonstrated  that  the  selected  4GL  provides  all  the  functions  needed  to  develop  a 
representative  application.  However,  the  PMO  is  buying  the  Structured  Query 
Language  server  and  the  selected  4GL  products  with  a  contract  sub-Contract  Line  Item 
Number  for  $2.2  million  in  FY 1996.  No  funds  were  budgeted  for  additional  software 
licenses  or  updates  that  are  probably  required  within  the  7  year  planned  software 
development. 

The  RCAS  Pilot  is  currently  underway,  including  a  PowerBuilder  5.0  application  which 
will  demonstrate  the  flexibility  and  performance  of  the  tool.  Funds  are  budgeted  for 
additional  software  licenses  and  updates  for  the  Software  Engineering  Environment 
throughout  the  program  life  cycle. 

Development  Language  Cost  Impact 

...  In  summary,  the  development  productivity  used  in  program  planning  was  14  to  20 
FP/MM.  But  Ada  or  other  approved  high-order  language  is  required  and  has  a  realistic 
development  productivity  of  three  to  five  FP/MM.  Therefore,  the  planned  productivity  is 
five  times  the  realistic  productivity  using  an  approved  language.  As  a  result,  the  time 
and  materials  funding  planned  is  underestimated  by  $150  million.  Our  $150  million 
estimate  is  consistent  with  the  Validation  Assessment  Team’s  cost  model.  The 
Validation  Assessment  Team  reported  that  if  4GLs  were  excluded  and  all  code  was 
developed  in  Ada,  there  would  be  a  net  increase  cost  for  software  and  data  of  $168. 7 
million. 
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The  following  is  an  extract  from  a  Capers  Jones  source  on  software  productivity. 

The  numeric  levels  of  various  languages  provide  a  convenient  shortcut  for  converting  size 
from  one  language  to  another.  For  example,  If  an  application  requires  1000  non* 
commentary  COBOL  statements  (level  3),  then  It  would  take  only  500  statements  In  a 
level  6  language  (such  as  NATURAL)  and  only  250  statements  in  a  level  12  language 
(such  as  OBJECTIVE  C). 

The  correlation  between  the  level  of  a  language  and  development  productivity  is  not 
linear.  For  most  large  software  projects,  coding  amounts  to  only  about  30  percent  of  the 
effort  Assume  a  program  is  written  in  a  language  that  is  twice  the  level  of  a  similar 
program,  for  instance  level  6  versus  level  3.  In  this  example,  the  coding  effort  might  be 
reduced  by  50  percent.  But  the  total  project  might  be  improved  by  only  15  percent,  since 
coding  only  comprised  30  percent  of  the  original  effort  Double  the  level  of  the  language 
again  to  a  level  12.  That  will  only  give  an  additional  7.5  percent  net  savings.  Once  again, 
coding  is  halved.  But  coding  is  not  a  major  factor  for  very  high  level  languages. 

More  accurate  economic  productivity  rates  can  be  gained  by  examining  the  average 
monthly  Function  Point  rates  associated  with  various  language  levels.  Table  1  looks  at 
how  language  levels  affect  productivity. 

Table  1 .  Language  Level  Relationship  to  Productivity 

LANGUAGE  LEVEL  PRODUCTIVITY  AVERAGE 
PER  STAFF  MONTH 


1-3  5  to  10  Function  Points 

4-8  10  to  20  Function  Points 

9-15  16  to  23  Function  Points 

16-23  15to30  Function  Points 

24  -  55  30  to  50  Function  Points 

Above  55  40  to  1 00  Function  Points 


Table  2.  Programming  Languages  and  Levels 
AVERAGE 

SOURCE  STATEMENTS 
LANGUAGE  LEVEL  PER  FUNCTION 
POINT 

Ada  83  4.50  71 

Ada  95  6.50  49 

PowerBuilder  20.00  16 


Softwsre  Productivity  Research 

Programming  Languages  Table,  Release  8.2,  MAR  94 

http://www.spr.com/Hbnry/langtbl.htm 

Table  2  above  is  an  extract  of  programming  languages  and  levels  for  Ada  83,  Ada  95, 
and  PowerBuilder  for  a  comparison  of  estimates.  The  development  productivity  (14  to 
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20  FP/MM)  used  in  program  planning  fits  well  within  the  Caper  Jones  range  of  15  to  30 
FP/MM.  Furthermore,  this  estimate  is  extremely  conservative  given  that  it  was  used  to 
estimate  only  the  effort  within  the  development  timebox.  The  cost  of  other  activities 
such  as  enterprise  modeling,  data  engineering,  functional  area  planning,  and 
development  management  were  estimated  separately.  Since  the  industry  average 
productivity  rates  reported  by  Capers  Jones  typically  include  many  of  these  costs,  the 
organizational  productivity  assumed  for  the  RCAS  developer  is  somewhat  lower  than 
the  14  to  20  FP/MM  reported.  Within  this  context  of  economic  productivity  correlation 
detailed  in  the  Software  Productivity  Research  documentation,  the  5:1  ratio  of  planned 
to  realistic  productivity  set  forth  in  the  Evaluation  Report  is  not  accurate. 

In  conclusion,  the  proposed  4GL  development  environment  is  in  compliance  with 
existing  policy  and  that  no  Ada  waiver  is  required,  the  forecasted  development 
productivity  is  realistic  and  the  funding  adequate.  Therefore,  an  additional  $150  million 
is  not  required. 

Other  Productivity  Risks 

The  RCAS  PMO  and  contractor  did  not  consider  other  productivity  adjustments  in  the 
above  calculations  for  either  Ada  or  the  selected  4GL.  Development  productivity 
reductions  for  the  very  large  project,  the  impact  of  the  new  development  process  Rapid 
Application  Fielding  Methodology,  and  the  development  contractor’s  Capability  Maturity 
Model  level  were  not  considered... 

...While  achievement  of  Capability  Maturity  Model  Level  2  improves  the  management 
foundation  of  the  software  organization,  the  production  amount  and  quality  is  still 
inconsistent  from  team  to  team  and  product  to  product.  This  inconsistency  combined 
with  the  organization's  growth  during  RCAS  does  not  support  the  planned,  steadily 
incmased  productivity  from  14  to  20  FP/MM. 

PMO  RCAS  carefully  considered  other  productivity  adjustments  in  the  calculations  for 
the  selected  4GL.  Statement  of  Work  paragraph  (Contract  Number  DAHC94-91-C- 
0002/P00296),  C. 3. 1.18  Software  Engineering  Institute  Capability  Maturity  Model 
Certification  states,  “The  Contractor  shall  achieve  a  Level  II  formal  assessment  in 
accordance  with  the  Software  Engineering  Institute  s  Capability  Maturity  Model  Version 
1.1.  This  certification  shall  be  achieved  on  or  before  the  Government’s  acceptance  of 
the  software  contained  in  LDP1." 

A  key  aspect  of  the  RCAS  managed  risk  approach  is  the  Integrated  Program 
Performance^Analysls  (IPPA).  IPPA  consists  of:  Cost  Performance  Reports,  Risk 
Management,  and  Integrated  Scheduling.  Production  amount  and  quality  consistency 
from  team  to  team  and  product  to  product  is  the  focus  of  the  SEI-based  Risk 
Management  Program.  The  attributes  of  the  Rapid  Application  Fielding  Methodology 
as  described  in  the  report  section  entitled,  ‘Software  Development  Approach’  are 
specifically  designed  to  abate  the  productivity  risks  enumerated  in  the  original  report. 
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Underestimated  Software  Maintenance 

...  The  contractor's  maintenance  estimate  was  based  on  a  15-16  percent  annual 
change  traffic.  The  15  percent  annual  change  traffic  is  based  on  historical  data  and 
assumes  a  7-year  life  cycle  for  software  (7  years  times  15-percent  =  105  percent). 

Our  very  conservative  calculation,  based  on  the  15-percent  annual  change  and  the 
above  size  estimates,  yields  a  range  of  17,900  to  36,000  FPs.  Fault  repairs  on  fielded 
software  are  not  included,  but  they  must  be  estimated  and  added  to  get  the  total 
maintenance  estimate.  By  selecting  18, 125  FP,  a  conservative  total  maintenance 
estimate,  we  calculated  that  the  software  maintenance  was  underestimated  by  12,000 
FP  (852,000  source  lines  of  code). 

Using  the  PMO  estimate  of  $61.2  million  for  the  total  60,500  FP,  we  determined  the 
additional  12,000  FP  will  cost  an  additional  $12.1  million. 

The  RCAS  VAT  estimates  for  Post-Deployment  Software  Support  (PDSS)  include  both 
fault  repairs  (bug  fixes)  and  enhancements.  The  estimate  is  based  on  annual  change 
volume  of  15%  of  installed  software,  with  25%  of  that  amount  for  fault  repair  and  75% 
for  enhancement.  However,  since  very  little  software  is  fielded  in  the  first  two  years, 
maintenance  costs  are  minimal  for  the  first  half  of  the  program. 

Maintenance  of  the  4GL  software  will  be  done  using  the  same  4GL  tool.  Since  this  tool 
is  more  of  a  prototyping  language  which  allows  both  user  and  developer  to  see  the 
results  of  their  efforts  much  more  quickly  than  with  a  3GL  language,  and  since  the  user 
will  be  Intimately  involved  in  the  timebox  development  effort,  there  should  be 
significantly  less  need  for  maintenance  to  correct  misinterpreted  user  requirements.  In 
addition,  because  the  4GL  is  a  higher  order  language  than  Ada  with  a  1 :5  ratio  in 
equivalent  lines  of  code,  the  total  volume  of  code  to  be  maintained  will  be  significantly 
less  than  if  it  were  written  completely  in  Ada. 

Recommendations  for  Corrective  Action 

A.  We  recommend  that  the  Chief,  National  Guard  Bureau: 

1.  Cease  further  data  and  applications  development  efforts  until  the  following 
actions  are  completed. 

A.  Select  Ada  (or  other  approved  computer  language)  as  required  by 
DOD  Directive  3405.1,  "Computer  Programming  Language  Policy,"  April  2,  1987,  before 
the  project  is  overcommitted  to  a  fourth-generation  language. 

B.  Reestimate  the  cost  and  schedule  of  the  project  based  on  realistic 
development  productivity  and  maintenance  sizing,  or  rescope  the  Data  and  Applications 
functions  to  fit  the  available  cost  and  schedule. 

Non-Concur.  RCAS  is  in  full  compliance  with  the  DOD  Ada  policy  which  treats 
advanced  software  technologies  (ASTs)  as  COTS  with  preference  over  Ada.  Mr.  Paige, 
ASD  (C3I),  reviewed  DOD  IG  Finding  A  and  has  concurred  in  writing  with  the  Program’s 
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_ _ _ _ _ _ e. 


approach.  Conservative  costs  and  schedules  have  been  proposed  based  on  Industry 
productivity  data  using  4GLs  such  as  PowerBuilder. 

2.  Require  full  justifications,  including  a  life-cycle  cost  analysis  and  a  risk 
analysis  that  addresses  technical  performance  and  schedule  impact,  if  an  Ada  waiver  is 
proposed. 

Non-Concur.  An  Ada  waiver  will  not  be  proposed  for  RCAS.  Nonetheless,  the  PMO 
has  reviewed  life-cycle  and  maintenance  costs.  A  risk  management  program  has  been 
established  which  will  address  technical  performance  and  schedule  impacts. 

3.  Cease  the  more  than  $2  million  procurement  of  Structured  Query  Language 
server  and  the  selected  fourth-generation  language  products  planned  for  FY 1996, 
unless  an  Ada  waiver  is  granted  and  pilot  applications  are  completed  successfully. 

Partial  Concur.  Since  RCAS  is  in  compliance  with  the  DOD  Ada  policy,  the  Program 
will  continue  to  acquire  COTS  development  tools  as  planned  for  FY  1996. 


Finding  B.  Telecommunications  Requirements  and  Funding 
The  Chief,  National  Guard  Bureau,  neither  identified  specific  telecommunications 
requirements  for  equipment  and  services  nor  determined  total  communications  cost  for 
the  RCAS  Program.  The  RCAS  PMO  did  not  complete  and  validate  requirements  for 
telecommunications  equipment  and  services.  Further,  the  RCAS  PMO  did  not  prepare 
site  surveys  to  identify  and  validate  the  cost  of  preparing  each  site  for  the  installation  of 
telecommunications  equipment  and  services.  As  a  result,  the  RCAS  PMO  has  not 
completed  a  documented,  validated,  and  comprehensive  telecommunications 
management  plan  to  obtain  the  most  cost-effective  telecommunications  circuit 
configuration  and  is  unable  to  determine  the  total  cost  of  the  telecommunications 
portion  of  the  RCAS  Program.  Therefore,  the  total  cost  of  RCAS  communications  is 
probably  underestimated  and  the  program  Is  probably  underfunded. 

Partial-Concur.  While  these  findings  were  partially  accurate  at  the  time,  the 
Telecommunications  plan  has  been  rewritten  with  participation  of  Army  National  Guard 
(ARNG)  and  the  U.S.  Army  Reserve  (USAR),  and  is  being  staffed  to  gain  the 
concurrence  of  Defense  Information  Systems  Agency  (DISA),  Information  Systems 
Engineering  Command  (ISEC),  Office  of  the  Secretary  of  Defense  (OSD)  (C3I),  and 
Director  of  Information  Systems  for  Command,  Control,  Communications,  and 
Computers  (DISC4).  This  staffing  will  be  completed  and  presented  at  the  MAISRC 
Milestone  III  decision  briefing  in  4th  Quarter  FY  96.  Specific  telecommunications 
requirements  are  identified  in  this  plan.  They  were  determined  using  an  accepted 
business  practice  of  modeling  the  telecommunications  requirements  based  on  empirical 
and  actual  data  collected  from  RCAS  customers.  The  ARNG  and  USAR,  who  do  all 
circuit  provisioning,  will  capitalize  on  existing  circuits  and  incorporate  RCAS 
requirements  into  their  future  telecommunication  plans.  The  RCAS  technical 
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architecture  solution  is  robust  and  flexible  enough  to  evolve  with  the  changing 
telecommunications  topology  without  causing  added  risk  to  the  system  operation.  The 
USAR  and  ARNG  have  indicated  their  concurrence  with  the  Telecommunications  Plan 
in  the  attached  memoranda  at  TABs  B  and  C. 

Telecommunications  Requirements 

...  Neither  the  RCAS  PMO  nor  the  vendor  validated  the  baseline  of  existing 
telecommunications  equipment  and  services  for  RCAS.  Specifically,  the  RCAS  PMO 
nor  the  vendor 

-  validated  the  number  of  subscriber  workstations  and  proposed  user 
requirements  for  future  telecommunications  equipment  and  services  for 
each  site,  or 

-  assessed  the  validity  of  proposed  user  requirements  to  establish  a 
telecommunications  configuration  management  plan 

A  Validation  Assessment  Team  consisting  of  representatives  from  the  prime  contractor, 
the  ARNG,  the  OCAR  and  the  USARC,  validated  the  number  of  subscriber 
workstations.  The  ARNG.  the  OCAR,  and  the  USARC  represent  the  user  community. 
The  number  of  subscriber  workstations  was  based  on  input  from  the  previously 
validated  RCAS  Functional  Description,  which  was  refined  and  revalidated  under 
Contract  Change  Proposal  (CCP)  022.  The  customer  representatives  participating  on 
the  Customer  Focus  Team  of  the  Validation  Assessment  Team  accepted  these 
numbers  as  meeting  the  basic  requirements  of  the  ARNG  and  USAR. 

The  RCAS  PMO  assessed  proposed  user  requirements  for  future  telecommunications 
equipment  and  services  for  RCAS  sites.  One  of  the  design  requirements  is  to  provide  a 
migration  path  from  legacy  electronic  mail  systems  to  the  Defense  Message  System 
(DMS).  At  the  time,  the  RCAS  was  restricted  by  public  law  (the  Brooks  Act)  from 
providing  services  other  than  those  offered  by  FTS200D.  However,  with  the  repeal  of 
the  Brooks  Act,  consolidation  of  telecommunications  requirements  with  other  ARNG 
and  USAR  requirements,  such  as  Distance  Learning,  is  possible  and  those 
requirements  are  being  incorporated  into  the  RCAS  Telecommunications  Plan,  the 
ARNG  Telecommunications  Plan,  and  the  USAR  Telecommunications  Plan.  A 
Migration  Transition  Plan  has  been  developed  for  DMS  by  Boeing  (System  Evolution 
Plan,  CDRL  D036,  Appendix  B). 

The  telecommunications  infrastructure  is  a  constantly  changing  environment.  The 
RCAS  Program  will  utilize  existing  telecommunications  resources.  The  Program  has 
specifically  addressed  this  by  insuring  that  RCAS  is  flexible  and  modular  in  design  so 
that  it  can  be  easily  adapted  into  the  customer’s  LAN.  All  modeling  and  budgeting  were 
done  on  a  worse  case  scenario.  In  reality,  we  should  be  able  to  save  money  by  using 
existing  capacity. 

The  RCAS  PMO  rationale  to  determine  the  quantity  of  telecommunications  equipment 
and  services  resulted  in  an  inadequate  identification  of  requirements.  Because  of  cost 
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constraints,  the  requirements  were  established  based  on  assumptions  and  on 
* recommended ’  minimum  priorities.  Therefore,  the  RCAS  PMO  and  the  vendor  have 
not  completed  a  documented,  validated,  and  comprehensive  telecommunications  plan. 

A  comprehensive  survey  of  over  4000  sites  would  be  required  to  resolve  this  issue.  This 
information  would  likely  be  out  of  date  by  the  time  the  sites  are  fielded.  Our  basis  of 
estimate  was  therefore  taken  from  the  approximately  2,100  units  that  have  been 
surveyed  and  fielded,  the  Installation  Plan  and  the  site  database  provided  by  the 
Government.  Subsequently,  25%  of  the  mini-hub  site  surveys  have  been  performed 
and  validated;  actual  costs  are  well  within  the  estimates.  Existing  equipment  for  GFE 
will  be  identified  during  the  Memorandum  of  Understanding  (MOU)  process. 

The  number  of  workstations  authorized  per  unit  was  established  as  a  result  of  extensive 
analysis  during  phase  1  and  documented  in  the  issue  Plan  (IP).  At  the  time  of  the 
MOU,  the  command  has  an  opportunity  to  adjust  quantities  between  units  up  to  a  finite 
number  of  workstations  per  command  identified  by  the  ARNG  and  USARC  during  the 
MOU  process.  The  IP  provides  a  planning  document  for  sizing  of  the 
telecommunication  network.  The  site  survey  process  captures  the  existing  customer 
telecommunication  plan  and  defines  the  requirements  just  in  time  for  the  receiving  unit. 
The  RCAS  prime  contractor  then  produces  a  facilities  requirement  engineering 
document  (FRED)  and  the  associated  bill  of  materials  (BOM)  for  each  receiving  unit. 

Telecommunications  Design 

Design-to-Cost  Strategy.  The  single  overriding  requirement  for  the  RCAS  was  a 
design-to-cost  constraint  imposed  on  the  functional  design  of  the  system.  As  a  result, 
some  of  the  detailed  requirements  are  not  met  or  are  only  partially  met.  For  example, 
the  requirement  to  allow  100-percent  growth  (quick  expandability)  in  the  quantity  of 
users  with  no  degradation  of  service  will  not  be  met. 

The  driving  force  was  the  exploitation  of  existing  capabilities  in  a  constantly  changing 
environment  The  customer's  telecommunication  system  is  growing  exponentially  in 
support  of  other  initiatives  (e.g.  Distant  Learning).  The  telecommunications  requirement 
for  RCAS  is  compatible  with  these  initiatives.  RCAS’  first  priority  is  to  utilize  existing 
telecommunications  systems  when  possible  and  establish  communications  capability 
where  necessary  to  meet  its  requirements. 

We  utilized  cost  as  an  independent  variable  to  insure  that  we  could  meet  the  user 
requirements  within  the  current  funding  profile  for  the  RCAS.  The  ARNG  and  USAR 
Customer  Focus  Team  developed  a  database  of  prioritized  user  needs  prior  to  the 
imposition  of  the  funding  profile.  The  prime  contractor  then  developed  a  system  design 
that  would  satisfy  ail  the  needs  identified  by  the  ARNG  and  USAR.  The  Customer 
Focus  Team  reviewed  this  system  design  and,  using  the  prioritized  user  needs 
database  as  a  guide,  eliminated  lowest  priority  needs  in  order  to  meet  the  funding 
profile.  In  the  case  of  the  given  example,  the  Customer  Focus  Team  decided  that 
maintaining  a  one-hundred  percent  excess  capacity  was  not  in  the  best  interest  of  the 
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ARNG,  the  USAR,  or  the  Government,  from  a  cost  point  of  view.  They  determined  that 
a  growth  capability  less  than  one-hundred  percent  is  acceptable  and  would  meet  the 
requirements  for  the  RCAS. 

Design-to-cost  shifted  the  responsibility  for  many  technical  support  functions,  such  as 
site  preparation  of  telecommunications  hubs,  circuit  ordering,  and  site  local  area 
network  (LAN)  wiring  for  small  sites  from  the  vendor  to  the  Army  National  Guard  and 
the  Army  Reserve.  However,  the  Army  National  Guard  and  the  Army  Reserve  may  not 
have  the  expertise  and  resources  necessary  to  perfonn  those  function. 

Site  preparation  of  telecommunications  hubs  remains  the  responsibility  of  the  RCAS 
PMO  through  the  prime  contractor.  The  Customer  Focus  Team  representatives, 
representing  their  respective  organizations,  accepted  the  responsibility  for  Local  Area 
Network  (LAN)  wiring  for  small  sites  and  circuit  ordering.  The  Customer  Focus  Team 
assumed  these  responsibilities  as  an  overall  cost  savings  measure.  The  Customer 
Focus  Team  stated  that  providing  funds  to  the  contractor  to  perform  these  functions 
was  unnecessary  because  their  available  resources  and  expertise  can  satisfy  these 
technical  support  functions  at  no  additional  cost  to  the  RCAS  Program.  The  RCAS 
Program  funds  previously  allocated  to  contractor  efforts  in  these  areas  could  then  be 
reprogrammed  to  meet  some  of  the  lower  priority  user  needs. 

Many  of  the  customers  already  have  existing  LANs  in  their  facilities.  RCAS  will 
maximize  the  use  of  the  existing  infrastructure  and  enhance  it  where  applicable.  This 
approach  has  been  validated  in  Iowa  where  we  are  riding  excess  bandwidth  that  meets 
our  requirements.  Additionally,  we  are  evaluating  the  ability  of  customers  to  perform  all 
their  site  preparation. 

Mainstream  COTS  products,  such  as  Microsoft,  Cisco,  Bay  networks,  etc.,  were 
carefully  chosen  for  the  solution.  These  are  dominant  vendors  in  the  industry  who 
provide  excellent  support  and  educational  services.  All  telecommunications 
components  are  pre-configured  before  they  are  shipped.  We  will  also  use  a  straight¬ 
forward  approach  to  network  design,  (e.g.,  we  will  use  Routing  Internet  Protocol  (RIP) 
rather  than  a  more  sophisticated  protocol  like  OSPF,  for  the  WAN  because  it  is  the 
most  simple  to  support).  Funds  have  been  allocated  for  training  System  Administrators. 

Further,  because  specific  requirements  for  telecommunications  equipment  and  services 
have  not  been  established,  the  RCAS  PMO  has  been  unable  to  determine  actual 
telecommunications  costs. 

The  RCAS  PMO  used  modeling  to  determine  telecommunications  costs.  Modeling  is 
an  accepted  industry  practice.  Modeling  is  a  quick,  cost-effective  method  for  accurately 
estimating  workload  and  costs.  The  model  used  by  the  RCAS  to  estimate 
telecommunications  costs  for  equipment  and  services  is  based  on  empirical  data, 
assumptions  approved  by  the  Customer  Focus  Team,  industry  standards,  and  industry 
practice.  While  a  model  will  not  provide  actual  costs,  it  does  provide  an  accurate 
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estimate  which  can  be  incorporated  into  the  program  cost  model  with  a  high  level  of 
confidence.  Actual  costs  can  only  be  determined  after  costs  are  incurred.  However, 
the  PMO  will  be  constantly  assessing  telecommunications  costs  throughout  the  life 
cycle  of  the  program. 

Site  Surveys.  The  RCAS  PMO  and  the  vendor  did  not  conduct  site  surveys  at  each 
location  to  obtain  a  valid  estimate  for  the  installation  cost  of  telecommunications 
equipment  and  services  for  RCAS. 

Since  modeling  produces  accurate  estimates,  conducting  site  surveys  at  this  point  in 
the  RCAS  life  cycle  would  greatly  increase  cost  with  no  added  benefit  to  the  Program. 
Site  surveys  are  expensive,  time  consuming,  and  produce  results  that  are  no  more 
accurate  than  those  produced  by  modeling.  Additionally,  lessons  learned  from  Phase  II 
of  the  RCAS,  show  that  performing  a  site  survey  more  than  six  months  prior  to  actual 
fielding  will  result  in  a  second  site  survey  visit.  It  would  be  cost  prohibitive  to  attempt  to 
obtain  these  estimates  any  sooner  due  to  the  constant  reorganizations  and  relocations 
within  the  Reserve  Component.  Instead  of  conducting  site  surveys,  an  approved  model 
was  used  to  estimate  the  costs  for  installation  of  telecommunications  equipment. 

Recommendations  for  Corrective  Action 

B.  We  recommend  that  the  Chief,  National  Guard  Bureau,  ensure  that  prior  to  any 
further  procurement  of  telecommunications  equipment  and  services  for  the  Reserve 
Component  Automation  System  Program,  the  following  actions  are  completed: 

a.  Determine  the  baseline  of  existing  telecommunications  equipment  and 
services,  and  validate  requirements  for  the  baseline  of  existing  telecommunication 
equipment  and  services. 

Non-Concur.  The  installed  base  of  RCAS  telecommunications  is  well  documented. 
This  baseline,  described  in  the  RCAS  Telecommunications  Plan,  consists  of  those 
circuits  installed  during  Phase  II  of  the  RCAS  contract.  The  requirement  for  these 
telecommunications  circuits  and  equipment  will  be  eliminated  as  those  currently  fielded 
sites  are  retrofit  into  the  new  RCAS  configuration.  Control  of  the  circuits  was 
transferred  to  the  ARNG  and  the  USAR,  along  with  funding  to  sustain  them  until  they 
are  no  longer  needed.  Existing  telecommunication  equipment  is  identified  for  reuse 
where  appropriate.  For  example,  there  are  sufficient  Secure  Data  Devices  (SDD)  so 
that,  when  redistributed  within  the  RCAS  Program,  no  additional  SDDs  will  need  to  be 
purchased. 

b.  Identify  the  number  of  subscribers;  determine  proposed  user  requirements  for 
future  telecommunications  equipment  and  services  for  each  site;  assesses  the  validity 
of  proposed  user  requirements;  and  complete  a  documented,  validated,  and 
comprehensive  telecommunications  configurations  management  plan  based  on 
validated  proposed  user  requirements. 
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Non-Concur.  The  number  of  RCAS  users  was  identified  by  the  ARNG  and  USAR. 

The  Customer  Focus  Team  has  concurred  that  the  current  fielding  plan  meets  the  basic 
requirements  for  the  ARNG  and  USAR. 

The  requirements  for  RCAS  telecommunications  equipment  and  services  are 
documented  in  the  System  Specification  and  Delivery  Subsystem  Specification.  The 
RCAS,  as  designed,  satisfies  those  requirements  identified  by  the  VAT  CFT  for 
implementation.  Other  user  requirements  for  the  ARNG  and  USAR  are  being  identified 
and  documented  by  the  RC.  These  requirements  are  documented  in  their 
telecommunications  plans.  The  RCAS  PMO  recognizes  the  need  to  consolidate  these 
requirements,  and  has  designed  a  modular  system,  which  can  easily  integrate  with 
other  systems,  as  they  are  designed,  developed,  and  implemented.  The  RCAS  PMO  is 
working  closely  with  the  RC  to  ensure  that  integration  and  consolidation  occurs,  where 
possible  and  appropriate. 

The  user  needs  were  established  by  the  Customer  Focus  Team  representatives  to  the 
Validation  Assessment  Team.  User  requirements,  are  documented  in  the  RCAS 
System  Specification,  Delivery  Subsystem  Specification,  and  Data  and  Application 
Subsystem  Specification. 

The  RCAS  performs  configuration  management  planning  and  execution  as  an 
integrated  effort.  While  there  is  no  requirement  for  a  telecommunications  specific 
configuration  management  plan,  the  configuration  management  plan  addresses 
telecommunications  components  as  integrated  critical  components  to  the  RCAS.  The 
RCAS  Telecommunications  Plan  has  been  rewritten  by  an  integrated  product  team 
(IPT)  with  participation  of  the  ARNG  and  USAR,  and  has  been  staffed  to  gain 
concurrence  of  DISA,  OSD(C3l),  iSEC,  and  DISC4.  The  plan  will  be  considered  final 
and  complete  with  the  concurrence  of  these  organizations  prior  to  MAISRC  Milestone  III 
decision  briefing  in  the  4th  Quarter  of  FY  96. 

c.  Determine  the  totel  cost  of  the  telecommunications  equipment  and  services 
portion  of  the  Reserve  Component  Automation  System  Program. 

Non-Concur.  The  cost  for  telecommunications  equipment  is  included  in  the  total 
hardware  cost  for  the  RCAS.  From  a  deployment  perspective,  it  makes  sense  to 
program  the  cost  of  telecommunications  infrastructure  along  with  the  equipment  being 
supported  by  that  infrastructure,  such  as  servers,  workstations,  and  printers. 
Telecommunications  services,  such  as  Frame  Relay,  Dial  lines,  and  Direct  Digital 
Service,  are  estimated  and  programmed,  along  with  non-recurring  installations  costs. 
These  costs  have  been  programmed  over  the  life  of  the  RCAS  contract,  using  several 
fielding  scenarios,  which  indicate  a  total  cost  estimate  of  $53  million.  The  various 
fielding  scenarios  proposed  affect  the  cost  of  telecommunications  services,  since 
accelerated  fielding  will  incur  costs  for  services  sooner  and  for  a  greater  period  of  time. 


15 


National  Guard  Bureau  Comments 


d.  Project  budgetary  costs  for  the  telecommunications  equipment  and  services 
portion  of  the  Reserve  Component  Automation  System  Program  and  establishes  a 
funding  program  for  the  Army  Reserve  and  the  National  Guard. 

Non-Concur.  Budgetary  costs  for  telecommunications  equipment  and  services  are 
included  in  the  RCAS  Program  budget.  The  NGB  and  OCAR  have  submitted  Program 
Operation  Memorandum  (POM)  to  establish  funding  for  the  RCAS  telecommunications 
costs. 


Finding  C.  Commercial  Off-theShelf  Infrastructure  Budget  Risks 
Budgeted  funds  to  purchase  the  RCAS  COTS  infrastructure  (personal  computers,  office 
automation  software,  and  telecommunications)  are  at  risk  from  other  areas  of  the 
Program  that  are  underbudgeted.  The  RCAS  Program  has  year-to-year  imbalances  of 
Other  Procurement  Army  (OPA)  funds  needed  to  finance  the  Boeing  contract. 
Additionally,  as  stated  in  Findings  A  and  B,  the  RCAS  PMO  has  underestimated 
software  development  and  has  not  determined  telecommunications  costs.  Insufficient 
infrastructure  investment  could  result  in  the  Army  National  Guard  and  Army  Reserve 
units  being  forced  to  wait  more  than  6  years  for  the  anticipated  benefits  from  deploying 
the  RCAS  commercial  off-the-shelf  infrastructure. 

Non-Concur.  Findings  A  and  B  are  addressed  in  previous  sections  of  this  report  and 
do  not  appear  to  be  a  cause  of  additional  funding  risk.  The  PMO  has  submitted  a 
request  for  a  realignment  of  funding  to  correct  the  imbalance  and  meet  the  needs  of  the 
contract  for  additional  OPA  funding.  The  fielding  approach  requires  seven  years 
because  of  the  funding  profile. 

Reserve  Component  Information  Requirements 

. . .  Due  to  the  important  need  to  provide  timely  and  accurate  information  and  to  improve 
the  accomplishment  of  administrative  tasks,  the  Army  National  Guard  and  the  Army 
Reserve  requested  that  the  PMO  RCAS  field  the  RCAS  COTS  infrastructure  within  3 
years.  Additionally,  the  General  Officer  Steering  Committee  endorsed  the  Army 
National  Guard  and  Army  Reserve  requests  by  recommending  that  the  PMO  RCAS 
pursue  a  high-level  fielding  strategy  for  FYs  1996  through  1998.  However,  the  current 
program  schedule  still  spreads  the  delivery  of  the  RCAS  COTS  infrastructure  to  the 
Army  National  Guard  and  the  Army  Reserve  over  a  7-year  period  due  to  funding 
constraints. 

The  fielding  approach  requires  seven  years  because  of  the  funding  profile.  The  PMO 
has  been  working  with  the  ARNG  and  USAR  to  modify  the  fielding  strategy  within  the 
seven  years  to  touch  as  many  users  as  possible  as  early  as  possible.  In  the  first  three 
years  we  are  retrofitting  the  entire  old  RCAS,  upgrading  all  government  furnished  PCs 
(10K),  installing  mini  hubs  at  all  major  commands  (by  April  97),  and  providing  funding 
for  the  customer  site  preparation. 
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Budget  Risks 

To  meet  the  COTS  infrastructure  delivery  schedule,  the  RCAS  PMO  must  manage  the 
risk  associated  with  the  OPA  budget  imbalances  and  funding  shortfalls  from  Findings  A 
and  B.  The  RCAS  PMO  budget  currently  contains  shortages  between  yearly  OPA 
funds  and  yearly  contract  commitments.  Also,  the  conditions  discussed  in  Findings  A 
and  B  may  cause  additional  risk  to  funds  designated  for  delivery  of  the  COTS 
infrastructure... 

Findings  A  and  B  are  addressed  in  previous  sections  of  this  report  and  do  not  appear  to 
be  a  cause  of  additional  funding  risk. 

Although  there  is  a  $68.2  million  management  reserve  in  FY  2003,  there  are  funding 
imbalance  shortfalls  fdrFYs  1999  to  2002.  Additionally,  even  though  reallocation  of 
funds  is  common  practice,  the  reallocation  jeopardizes  the  current  fielding  plan  for  the 
RCAS  COTS  infrastructure. 

The  RCAS  Program  finalized  a  complete  restructure  on  31  January  1996.  Fundamental 
to  the  cost  as  an  independent  variable  (CAIV)  analysis  was  the  portability  of  funds 
across  appropriations  in  the  Program  Objective  Memorandum  (POM)  years.  Our  POM 
request,  submitted  on  19  April  1996,  implemented  the  changes  consistent  with  the 
restructured  program  requirements.  The  realignment  of  funding  was  essential  in  order 
to  correct  the  imbalance  and  meet  the  needs  of  the  contract  for  additional  OPA  funding. 

In  establishing  the  funding  adequacy  and  executability  of  the  program,  only  funds  from 
FY  96  through  02  have  been  considered.  In  the  recently  completed  POM  development 
cycle,  funding  was  requested  for  FY  03  to  accommodate  a  smooth  program  transition 
from  the  program  management  office  to  whatever  organization  will  take  over 
management  of  the  system.  As  a  result  of  the  POM,  the  program  is  currently  funded  for 
$46.7  million  in  FY  03,  but  as  stated  previously,  these  funds  have  not  been  considered 
as  part  of  the  CAIV  target  funding.  These  funds  are  not  management  reserve. 

Correcting  O&M  and  OPA  Imbalance  (Feb  96) 
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...the  Army  National  Guard  and  the  Army  Reserve  have  requested  $235.3  million  in 
their  Program  Objective  Memorandum  for  FYs  1998  through  2003  to  cover  RCAS  O&M 
costs.  Neither  the  Army  National  Guard  or  the  Army  Reserve  have  funds  earmarked  for 
RCAS  O&M  in  FYs  1996  and  1997. 
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PMO  RCAS  has  budgeted  for  the  O&M  costs  for  telecommunications  through  FY99  and 
the  customer  proponents  assume  the  costs  starting  in  FYOO,  and  have  assumed 
responsibility  for  acquiring  the  necessary  funds  through  the  POM  process. 


RCAS  Schedule 
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C.  We  recommend  that  the  Chief,  National  Guard  Bureau: 

1.  Formally  baseline  the  RCAS  commercial  off-the-shelf  hardware  and  software 
infrastructure  delivery  schedule  and  quantities. 

Concur.  The  RCAS  PMO  continues  to  finalize  the  Program  Baseline  in  preparation  for 
a  DOD  MAISRC  Milestone  III  decision  to  field  the  infrastructure.  The  MAISRC 
Milestone  III  decision  briefing  is  scheduled  for  late  in  the  4th  Quarter  of  FY  96. 

2.  Ensure  that  multiple  use  of  existing  computer  systems  is  considered  to  further 
support  the  Reserve  Component  users. 

Concur.  The  RCAS  solution  will  capitalize  on  already  existing  investments  in  computer 
systems.  The  ARNG  and  USAR  have  committed  to  providing  10,000  of  their  existing 
computer  resources  as  part  of  the  RCAS  solution.  The  Specification  Control  Drawing 
for  the  Workstation  Configuration  Items  (Cl)  specifies  the  minimum  system 
requirements  necessary  for  the  RCAS  solution.  In  addition,  the  RCAS  solution  is  based 
on  an  open  architecture  which  allows  each  unit  to  connect  other  computer  equipment  at 
their  discretion. 

CONCLUSION:  The  PMO  has  reviewed  the  findings  and  recommendations  of  the  DOD 
IG  and  believes  the  issues  have  been  adequately  addressed  and  mechanisms 
established  which  will  monitor  these  and  other  risk  areas  without  having  to  cease 
progress  on  the  Program.  The  PMO  feels  strongly  that  the  Program  can  continue  to 
move  forward  while  tracking  these  and  other  risk  areas. 
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DEPARTMENT  OF  THE  ARMY 

HEADQUARTERS,  UNITED  STATES  ARMY  RESERVE  COMMAND 
3*M  NORTH  CAMP  CREEK  PARKWAY  SW 
ATLANTA,  OA  M331-SM* 


AFRC-IMP  (25)  ,  9  JUH  193S 


MEMORANDUM  THRU  Program  Management  Office,  Reserve  Component 
Automation  System,  8510  Cinderbed  Road, 
Newington,  VA  22122-8510 

FOR  Inspector  General,  Department  of  Defense,  ATTN:  ROS, 

400  Army  Navy  Drive,  Arlington,  VA  22204-2884 

SUBJECT:  Evaluation  of  the  Reserve  Component  Automation  System 

(RCAS)  Telecommunication  Plan 


1.  The  purpose  of  this  memorandum  is  to  express  the  United 
States  Army  Reserve  (USAR)  concurrence  that  the  RCAS 
Telecommunication  Plan  represents  a  baseline  telecommunication 
design  and  plan  which  will  support  the  data  and  e-mail 
requirements  of  the  Army  Reserve.  However,  the  USAR  and  PMO  have 
agreed  to  maximize  the  use  of  all  existing  telecommunications 
resources  where  USAR  RCAS  requirements  can  be  handled  by  existing 
networks.  Where  no  telecommunication  network  exists,  the  RCAS 
Telecommunication  Plan  will  be  implemented. 

2.  The  RCAS  model  was  built  on  assumptions  provided  by  the 
United  States  Army  Reserve  Customer  Focus  Team  representatives 
during  the  Validation  Assessment  Team  process.  The  workload 
assumptions  reflect  the  projected  workload  for  the  USAR  as 
presented  by  the  original  functional  area  inputs  and  subsequent 
updates.  We  accept  the  projections  as  the  best  possible  data 
available . 

3 .  The  cost  estimates  generated  as  a  result  of  the  model  reflect 
the  projected  coBt  for  the  baseline  RCAS  design.  The  RCAS 
Program  Management  Office  has  transferred  funds  to  the  Army 
Reserve  to  support  RCAS  telecommunications  for  the  remainder  of 
FY  96.  The  RCAS  will  continue  to  transfer  funds  to  USARC  through 
FY  99,  at  which  time  the  United  States  Army  Reserve  will  accept 
the  telecommunications  costs.  Modeling  and  cost  estimates 
indicate  a  significant  overall  telecommunication  cost  reduction 
when  data  (RCAS)  and  other  communication  services  are  combined. 


Department  of  the  Army  Comments 


AFRC-IMP 

SUBJECT:  Evaluation  of  the  Reserve  Component  Automation  System 

(RCAS)  Telecommunication  Plan 


The  USAR  has  submitted  Program  Objective  Memorandum  (POM)  to 
support  the  integrated  RCAS  telecommunication  costs  through  the 
_end  of  its  life  cycle. 

4 .  The  USAR  will  support  the  current  RCAS  telecommunication  plan 
for  the  Operations  Integration  Site  (OIS)  test  based  upon  an 
agreement  by  the  PM  RCAS  to  aggressively  pursue  migration  to  a 
new  integrated  telecommunications  solution  on  or  before  the  next 
contract  period. 

5.  The  United  States  Army  Reserve  stands  ready  to  work  with  the 
Army  National  Guard,  the  PM  RCAS,  Information  Systems  Engineering 
Command,  U.S.  Army,  Program  Manager,  Defense  Message  System-Army, 
the  Defense  Information  Systems  Agency,  and  Boeing  Information 
Services,  Inc.,  to  identify  the  most  cost  effective  telecom¬ 
munications  solution  for  both  the  ARNG  and  the  USAR.  We  further 
look  forward  to  our  working  together  with  the  concerned  parties 
to  consolidate  requirements  and  eliminate  any  and  all  duplication 
of  telecommunication  resources. 

6.  For  further  information  on  this  action,  please  contact  the 
USARC  RCAS  Coordination  Office,  (404)  629-8941  (LTC  Kirby)  or 
(404)  629-8203  (LTC  Gray) . 

a 

CAROKMJ  E.  RUSSELL 

Colonel,  GS 

Deputy  Chief  of  Staff, 

Information  Management 

CF: 

USARC,  AFRC-IMO  (Mr.  Hicks) 

USARC,  AFRC-IMO-TF  (Mr.  Overpeck) 
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DEPARTMENTS  OF  THE  ARMY  AND  THE  AIR  FORCE 
NATIONAL  GUARD  BUREAU 
111  SOUTH  GEORGE  MASON  DRIVE 
ARLINGTON,  VA  22204-1382 


NGB-AIS  (25-la) 


JUN  I  3  »99S 


MEMORANDUM  THRU  PROGRAM  MANAGEMENT  OFFICE,  RESERVE 
COMPONENT  AUTOMATION  SYSTEM,  8510 
CINDERBED  ROAD,  NEWINGTON,  VA 
22122-8510 

FOR  INSPECTOR  GENERAL,  DEPARTMENT  OF  DEFENSE.  ATTN:  ROS, 
400  ARMY  NAVY  DRIVE,  ARLINGTON,  VA  22204-2884 

SUBJECT:  Evaluation  of  the  Reserve  Component  Automation  System  (RCAS) 
Telecommunication  Plan 


1 .  The  purpose  of  this  memorandum  is  to  express  the  Army  National  Guard  (ARNG) 
concurrence  that  the  RCAS  Telecommunication  Plan  represents  a  baseline 
telecommunication  design  and  plan  which  will  support  the  data  and  e-mail 
requirements  of  the  Army  National  Guard.  However,  the  ARNG  and  PMO  have 
agreed  to  maximize  the  use  of  all  existing  telecommunications  resources  where 
ARNG  RCAS  requirements  can  be  handled  by  existing  networks.  To  that  end,  the 
most  cost  effective  design  for  satisfying  the  RCAS  requirements  is  to  integrate  the 
RCAS  data  traffic  into  the  ARNG  ATM  backbone  network  (GUARDNET  XXI)  and 
other  existing  state  networks.  Where  no  telecommunication  network  exists,  the 
RCAS  Telecommunication  Plan  will  be  implemented. 

2.  The  RCAS  model  was  built  on  assumptions  provided  by  the  Army  National  Guard 
Customer  Focus  Team  representatives  during  the  Validation  Assessment  Team 
process.  The  workload  assumptions  reflect  the  projected  workload  for  the  ARNG  as 
presented  by  the  original  functional  area  inputs  and  subsequent  updates.  We 
accept  the  projections  as  the  best  possible  data  available. 

3.  The  cost  estimates  generated  as  a  result  of  the  model  reflect  the  projected  cost 
for  the  baseline  RCAS  design.  The  RCAS  Program  Management  Office  has 
transferred  funds  to  the  Army  National  Guard  to  support  RCAS  telecommunications 
for  the  remainder  of  FY96.  The  RCAS  will  continue  to  transfer  funds  to  NGB  through 
FY99,  at  which  time  the  Army  National  Guard  will  accept  the  telecommunications 
costs.  Modeling  and  cost  estimates  indicate  a  significant  overall  telecommunication 
cost  reduction  when  data  (RCAS)  and  other  communication  services  are  combined. 
The  ARNG  has  submitted  Program  Objective  Memorandum  (POM)  to  support  the 
integrated  RCAS  telecommunication  costs  through  the  end  of  its  life  cycle. 
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NGB-AIS 

SUBJECT:  Evaluation  of  the  Reserve  Component  Automation  System  (RCAS) 
Telecommunication  Plan 

4.  The  ARNG  will  support  the  RCAS  telecommunication  plan  for  the  Operations 
Integration  Site  (OIS)  test  based  upon  an  agreement  by  the  PM  RCAS  to 
aggressively  pursue  migration  to  the  GUARDNET  XXI  solution  on  or  before  the  next 
contract  period. 

5.  The  Army  National  Guard  stands  ready  to  work  with  the  U.S.  Army  Reserve,  the 
PM  RCAS,  Information  Systems  Engineering  Command,  U.S.  Army,  Program 
Manager,  Defense  Message  System-Army,  the  Defense  information  Systems 
Agency,  and  Boeing  Information  Services,  Inc.,  to  identify  the  most  cost  effective 
telecommunications  solution  for  both  the  ARNG  and  the  USAR.  We  further  look 
forward  to  our  working  together  with  the  concerned  parties  to  consolidate 
requirements  and  eliminate  any  and  all  duplication  of  telecommunication  resources. 

6.  The  Point  of  Contact  for  this  action  is  Mr.  Gene  A.  McDaniel,  DSN  327-9631 . 
FOR  THE  CHIEF,  NATIONAL  GUARD  BUREAU: 


UJjjUk»~v 

WILLIAM  M.  SANSING  ^ 
COL,  NGB 

Director,  Information  Systems 
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